On 3 June 2014 10:23, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 02/06/2014 18:17, Peter Maydell ha scritto: > >> Um. This feels like we're wrongly overloading this flag for >> more than one thing. "Is the user-mode binary BE8?" is >> definitely not a property of the CPU, so it shouldn't be >> a CPU state flag. (Conversely, "is the iside endianness the >> opposite way round to TARGET_WORDS_BIGENDIAN" is a CPU >> property of sorts.) It seems to me that we probably want >> to fix this by more correctly modelling the actual CPU >> state involved here, by having user-mode either set or >> not set SCTLR.B [set only if BE32 binary], and the data >> and insn fetches honour both that and CPSR.E appropriately.) > > > So basically it's s/bswap_code/!sctlr_b/. Thanks for the suggestion!
Actually I was thinking again about this last night, and user-mode is a bit odd, since it's the only place we ever have TARGET_WORDS_BIGENDIAN set. System emulation: TARGET_WORDS_BIGENDIAN indicates the "bus endianness", always LE for ARM. User emulation: TARGET_WORDS_BIGENDIAN indicates the "kernel API endianness", so may be BE or LE. In system emulation it's clear how we should implement things: TARGET_WORDS_BIGENDIAN is never set, data accesses honour CPSR.E by doing MO_BE or MO_LE accesses, instruction accesses are always MO_LE, and SCTLR.B is implemented by XORing the address with 3 (for byte accesses) or 1 (for halfword accesses). [SCTLR.B is word-invariant big-endian, hence the need to use XORs. In practice since there's not much interest in system emulation of BE32 we can leave it unimplemented.] In user emulation, things are more complicated for BE32, because we're sort of emulating the word-invariant bigendian using byte-invariant big-endian (this is safe because there's no way for a userspace program to get at anything that would let it tell the difference). So we can't just say "set SCTLR.B and handle as if SCTLR.B is set in the way system emulation would", because the behaviour has to be different. So in summary I'm not sure of the right approach any more... thanks -- PMM
