qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/34] tcg, target/ppc vector improve


From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/34] tcg, target/ppc vector improvements
Date: Tue, 18 Dec 2018 15:26:42 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0

On 18/12/2018 15:17, Richard Henderson wrote:

> On 12/18/18 7:05 AM, Mark Cave-Ayland wrote:
>> On 18/12/2018 09:49, Mark Cave-Ayland wrote:
>>
>>> Following on from this, the next patch "target/ppc: convert vsplt[bhw] to 
>>> use vector
>>> operations" causes corruption of the OS X splash screen
>>> (https://www.ilande.co.uk/tmp/qemu/badapple2.png) in a way that suggests 
>>> there may be
>>> an endian issue.
>>
>> Changing "#ifndef HOST_WORDS_BIGENDIAN" to "#ifdef HOST_WORDS_BIGENDIAN" in 
>> this
>> patch helps a lot, but something still isn't quite right:
>> https://www.ilande.co.uk/tmp/qemu/badapple3.png.
> 
> I can't figure out what the host+guest endian rules for ppc_avr_t are at all.
> 
> Certainly there appear to be bugs wrt vscr and which end of the register we
> pull the value.  On the tcg side we take host endianness into account, and on
> the gdb side we always use u32[3].

That seems wrong to me. Given that the ppc_avr_t is a union then I'd expect it 
to be
in host order? Certainly in the VMX helper macros I've looked at, the members 
are set
directly with no byte swapping.


ATB,

Mark.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]