On 15 July 2013 15:01, Anthony Liguori <anth...@codemonkey.ws> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: >> On 12 July 2013 23:50, Benjamin Herrenschmidt <b...@kernel.crashing.org> >> wrote: >> I agree that TARGET_WORDS_BIGENDIAN *should* go away, but >> it exists currently. Do you actually implement a CPU which >> does dynamic endianness flipping? > > TCG already supports bi-endianness for PPC. Grep for 'le_mode' in > target-ppc/translate.c to see how the TCG instruction stream is affected > by it.
Right, that's what I thought. This means that if you're on a little-endian host and using a PPC chip in le-mode then the QEMU infrastructure will byteswap the data, and then those generated bswap* ops will byteswap it again. It would be more efficient if we supported dynamically having the emulated CPU specify whether it wanted a BE or LE memory access, and then byteswapping the correct number of times based on device/host endianness/CPU setting. (This would also avoid ugliness like the current ARM BE8 code which should be doing "BE read for data, LE read for instructions" and instead has to do "BE read of everything via TARGET_WORDS_BIGENDIAN and then swap the instruction words again to get back to LE".) If we ever want to support multiple different CPUs in one model we'll need this anyway, because one might be BE and another LE. > On PPC, le_mode only really affects load/stores and instruction > decoding. Any shared data structures between the CPU and OS remain big > endian. > > So TARGET_WORDS_BIGENDIAN is still accurate even when > le_mode=1. It's not the semantic equivalent of > changing TARGET_WORDS. I'm not sure what you mean by "accurate" here. It's a compile time switch, when the hardware we're actually emulating does runtime (dynamic) switching, and when the current runtime mode doesn't match the compiled-in setting we end up doing unnecessary double-swap operations. thanks -- PMM
