qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Streamlining endian handling in TCG


From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC] Streamlining endian handling in TCG
Date: Wed, 28 Aug 2013 18:28:47 +0100

On 28 August 2013 18:16, Richard Henderson <address@hidden> wrote:
> On 08/28/2013 09:38 AM, Peter Maydell wrote:
>>> (B) Add an additional bit to the "opc" to indicate which endianness is 
>>> desired.
>>>  E.g. 0 = LE, 8 = BE.  Expose the opc interface to the translators.  At 
>>> which
>>> point generating a load becomes more like
>>>
>>>     tcg_gen_qemu_ld_tl(dest, addr, size | sign | dc->big_endian);
>>>
>>> and the current endianness of the guest becomes a bit on the TB, to be 
>>> copied
>>> into the DisasContext at the beginning of translation.
>>
>> I guess we deal with ARMv5-style BE32 by having the target
>> emit an explicit XOR TCG op?
>
> Yes.  I see no other way to implement that.
>
>> Do we need to overhaul the C interface to the
>> memory system too? (ie ldl_p and friends).
>
> I don't think so, since we already have ldl_{le,be}_p.

Well, what do ldl_p or ldl_phys or any of the other functions
without an le/be qualifier mean any more if "is this CPU in
big endian mode?" now requires you to have a CPUState
to ask? I guess we can tackle that separately from getting
the assumptions on endianness out of the tcg backends
though.

-- PMM



reply via email to

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