Re: [Qemu-devel] [PATCH 01/15] exec: introduce endianness swapped mmio

[Peter Maydell]

On 26 November 2010 23:00, Andreas Färber <address@hidden> wrote:
> Am 25.11.2010 um 08:35 schrieb Alexander Graf:
>> +    switch (endian) {
>> +    case DEVICE_BIG_ENDIAN:
>> +#ifndef TARGET_WORDS_BIGENDIAN
>> +        swapendian_init(io_index);
>> +#endif
>> +        break;
>
> So basically, you just moved the #ifdefs to another place. :) Shouldn't this
> be dependent on the CPU state and determined at runtime? Thinking of MSR LE
> bit on ppc. I guess QEMU doesn't support bi-endian ppc today, as does the
> 970, but it would be nice to keep it in mind.

I was wondering about that (ARM actually has two different 'big endian'
modes, one of which is byte-invariant and one of which is word-invariant,
and which are runtime selectable on at least some cores...) But
I think I agree with Paul Brook that endianness as we're considering it
here is really kind of a bus level property, and TARGET_WORDS_BIGENDIAN
is defining a sort of "system bus endianness". Runtime flippable cores
do the swapping in generated code before they get out to this bit, which
corresponds to how the hardware does it (things get swapped before they
get out to the signals external to the core).

That does mean that in some cases you end up doing a double byteswap,
but my guess would be that the slowdown on doing that for device access
is completely buried by the slowdown on having to do that for RAM access,
so it's not worth worrying about.

-- PMM