[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 #22 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #18)
> (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
>

exactly.  which is precisely what i cannot cope with, and require quite
literally a brute-force search on permutations of parameters when writing code,
in order to get it right.

please don't push any more on this jacob.  please accept that if i cannot cope,
and get confused, there is no way i will be able to confidently explain it and
justify it to the OPF ISA WG.

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