Re: [Qemu-devel] RFC: reverse-endian softmmu memory accessors

["Blue Swirl" <blauwirbel@gmail.com>]

On 10/14/07, J. Mayer <l_indien@magic.fr> wrote:
> On Sat, 2007-10-13 at 16:17 +0200, J. Mayer wrote:
> > On Sat, 2007-10-13 at 16:07 +0300, Blue Swirl wrote:
> > > On 10/13/07, J. Mayer <l_indien@magic.fr> wrote:
> > > > On Sat, 2007-10-13 at 13:47 +0300, Blue Swirl wrote:
> > > > > On 10/13/07, J. Mayer <l_indien@magic.fr> wrote:
> > > > > > 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...).
> > > > >
> > > > > Nice, this may be useful for Sparc64. It has a global CPU flag for
> > > > > endianness, individual pages can be marked as reverse endian, and
> > > > > finally there are instructions that access memory in reverse endian.
> > > > > The end result is a XOR of all these reverses. Though I don't know if
> > > > > any of these features are used at all.
> > > >
> > > > I realized that I/O accesses for reverse-endian pages were not correct
> > > > in the softmmu_template.h header. This new version fixes this. It also
> > > > remove duplicated code in the case of unaligned accesses in a
> > > > reverse-endian page.
> > >
> > > I think 64 bit access case is not handled correctly, but to solve that
> > > it would be nice to extend the current IO access system to 64 bits.
> >
> > I think that if it was previously correct, it should still be, but... I
> > don't know how much having 64 bits I/O accesses is interresting, as I
> > don't know if there are real hw buses that have 64 bits data path...
> >
> > Here's another version taking care of your remark about ldl memory
> > accessors.
> > * I replaced all ldl occurences with ldul
> > * when TARGET_LONG_BITS == 64, I also added ldsl accessors. And I
> > started using it in the PowerPC memory access micro-ops.
> > Then the patch is really more invasive than the previous ones.
> > This still does not break PowerPC or i386 target, as it seems.
>
> Here's a new version. The only change is that, for consistency, I did
> add the big-endian and little-endian accessors that were documented in
> cpu-all.h as unimplemented. The implementation is quite trivial, having
> native and reverse-endian accessors available, and changes functionnally
> nothing to the previous version.

The patch does not apply anymore. The Sparc part looks OK.

The benefits from the patch can be gained by mapping Sparc64 lduw and
ldsw in op_mem.h  directly to ldul and ldsl using SPARC_LD_OP and
replacing the ldl+bswap etc. for the LE cases with ldlr in
op_helper.c. If you prefer, I can do this after you have applied the
patch.