[Libre-soc-isa] [Bug 560] big-endian little-endian SV regfile layout idea

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=560

--- Comment #18 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #16)
> (In reply to Alexandre Oliva from comment #12)
> 
> > now, I don't know what LE SRAM really means. 
> 
> see the union datastructure.
> https://libre-soc.org/openpower/sv/overview/#elwidths
> 
> 
> > to me, the register file has
> > no endianness whatsoever; 
> 
> in a scalar system you would be absolutely correct.
> 
> with the elwidth overrides effectively being a union of
> 
> uint8_t []
> uint16_t []
> uint32_t []
> uint64_t []
> 
> now the underlying order *does* matter.
> 
> you set b[1] to 0x55 does that mean that w[0] contains 0xnnnn55nn?
> 
> if the underlying SRAM is treated as LE the answer is YES.
> 
> if the underlying SRAM of the regfile is treated as "a direct representation
> of memory" i will be LITERALLY unable to cope with the complexity introduced
> due to MASSIVE confusion as to what is now in which order.

it means the registers act just like memory, so little-endian gives w[0] ==
0xnnnn55nn, and big endian gives w[0] == 0xnn55nnnn

> > so as to avoid the risk that loading a single byte, using
> > a vector-prefixed scalar load, lands it in the MSByte of the register,
> > unlike the byte-load instruction.  alas, with big endian, it looks like the
> > natural whole-register array layout would map the first element to the
> > most-significant end of the register instead.
> 
> correct.  hence why i consider it to be a dangerous idea, and had already
> naturally assumed that the SRAM would be LE, such that the c-based union
> would be an accurate and definitive representation.

In my proposal it *is* still the completely accurate and definitive version,
just that the C union for registers is compiled with the same endianness as
memory.

-- 
You are receiving this mail because:
You are on the CC list for the bug.