The problem:
some CPU architectures, namely PowerPC and maybe others, offers
facilities to access the memory or I/O in the reverse endianness, ie
little-endian instead of big-endian for PowerPC, or provide instruction
to make memory accesses in the "reverse-endian". This is implemented as
a global flag on some CPU. This case is already handled by the PowerPC
emulation but is is far from being optimal. Some other implementations
allow the OS to store an "reverse-endian" flag in the TLB or the segment
descriptors, thus providing per-page or per-segment endianness control.
This is mostly used to ease driver migration from a PC platform to
PowerPC without taking any care of the device endianness in the driver
code (yes, this is bad...).

Proposal:
here's a patch that implement "reverse-endian" low-level memory
accessors. It also provide an IO_MEM_REVERSE flag for TLBs. This flag is
handled in the I/O case of softmmu low-level routines which means that
it does not slowdown "native-endian" memory accesses and only add a
one-bit test on the "native-endian" I/O access, which should not be a
problem as I/O accesses are already slower, being handled via a
callback. As a side effect this patch allows me to delete large parts of
the target-ppc/op_mem.h and target-ppc/op_helper_mem.h as it makes
little-endian memory accessors directly available. And the translated
code for all little-endian access also becomes smaller, which has even a
visible effect on the mean translated block size (as reported by the
"info jit" monitor command) as lwbrx and lhbrx, which does memory
accesses with byteswap, are widely used in PowerPC code.

Warning:
this patch is to be taken as a proof of concept, for now. It works and
does not bring any visible regression to the PowerPC emulation but may
be bugged somewhere and generates conflicts if applied against the
CPU_MMU_INDEX patch. It is very invasive in the PowerPC target code but
needs just a few adds for other targets. It also brings quite a lot of
changes in the softmmu headers but is supposed not to change the
"native-endian" pathes (or it's a bug).
One will also notice that I also added "reverse-endian" byte access
routines. Those are, in fact, not needed but I let them just for
consistency.

Please comment.

-- 
J. Mayer <l_indien@magic.fr>
Never organized