Little-endian YDL?

[Tim Seufert]

On Nov 21, 2003, at 6:02 AM, Robert Sanders wrote:

> Egads!  I think my 'yeesh' from a previous reply wasn't strong enough. 
>  So the PPC in LE mode is going to take
> a 32bit number, drop it into the space of a 64 bit (disregarding the 
> 'high' bits) in BE mode, *access* the bytes
> in reverse from the high end of the BE 64 bit space?!

The processor is really still doing everything in BE order.  The 3 low 
order address bits for every load/store are "munged", with different 
munges for different operand sizes.  In the case of a 32-bit operand 
the munge is to flip bit 2, so a word stored to offset 4 goes to offset 
0 and vice versa.  16-bit accesses flip bits 2 and 1.  Byte accesses 
flip all three low order bits, which ends up transposing addresses 0 
and 7, 1 and 6, 2 and 5, 3 and 4.  64-bit accesses, i.e. floating point 
doubles, flip nothing at all.  I forget what they did when they added 
128-bit memory operations with AltiVec, which do not fit well with the 
64-bit oriented address munging.

So, if we look at the PPC LE image of 0x01020304 stored to address 0 
which I posted earlier:

mem[0] = (Not changed)
mem[1] = (Not changed)
mem[2] = (Not changed)
mem[3] = (Not changed)
mem[4] = 0x01
mem[5] = 0x02
mem[6] = 0x03
mem[7] = 0x04

If you tried to access byte 0 of 0x01020304 on a BE processor, you'd 
get 0x01.  On a LE processor, you'd get 0x04.  On PPC with the LE bit 
set, trying to load a byte from address 0 will actually read address 7 
(bits 0, 1, and 2 of the address are flipped) and you get 0x04.

A 16-bit read of address 0 actually reads address 6 after bits 1 and 2 
of the address are flipped, so you get 0x0304, which once again is what 
you'd expect on a LE processor.

The real horror comes when they start talking about how PPC LE mode 
handles misaligned accesses (all of the above assumes operands are 
naturally aligned).  I don't pretend to understand that offhand.