[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 #16 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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.




> each register holds a number of bits, from least
> to most significant, that get ordered one way or another, depending on
> hardware configuration, when storing the register in memory, or when loading
> it from memory. 

yes.  and OpenPOWER has some strict rules that took 5 months to correctly
implement.

i am simply not going through that again.


> memory has endianness, because it's external to the cpu,
> and it can be accessed and addressed in different granularities; registers
> don't, because they are conceptually just a collection of flip-flops that
> are operated on as a coherent unit

in a scalar system yes.

in any other vectir system yes.

in our extremely unique system which is effectively a union typecast of
different c style arrays with an underlying uint8_t[8] array...

... no.


>  arguing about their bit order is like
> arguing whether the flip-flops have to be ordered left-to-right or
> right-to-left.  it doesn't matter, as long as the wiring connects each bit
> to the right place. 

again: this is correct for scalar ISAs, correct for normal vector ISAs, and
completely wrong for SV due to us using the 64 bit scalar regfile to store
sequential array overloads.


> having expressed this distinction on how I reason, hopefully it will be
> clear why your response is not an answer to my question. 

it allows me to highlight the error in that reasoning, yes 

> you don't get down
> to the memory addresses, you just number the bytes of the registers, which
> might be ordered by significance, 

no.  a decision has to be made as to which order the uint8[] array elwidth
override will place bytes into the underlying 8 bytes of the register.

this categorically and definitively decides in which order the byte-level
WRITEENABLE lines will be pulled and numbered: backwards or forwards.

i CANNOT COPE if those numbers are calculated by forcibly subtracting them from
7 in some cases, 3 in others, 1 for halfwords.

it's just an absolute recipe for disaster.

therefore the ordering *IS* LE SRAM order.



> or by corresponding memory address if
> stored.
> 
> now, does assuming "LE processor mode" imply we don't care about BE at all? 
> that would remove a lot of the potential complications I was running up
> against.

the decision has already been made to support Scalar OpenPOWER LE/BE and the
code is already in the repository with unit tests passing.

due to it taking 5 months to spot bugs i do not want to touch it again without
a damn good reason.

> or are you talking about code vs data endianness? (IIRC PPC can choose them
> separately)

it can.  we are not.

> 
> anyway, *my* suggestion was just that the iteration order over sub-register
> vector elements made it so that the first element matched the register when
> used as a scalar,

which is achieved by setting LE SRAM order in the underlying SRAM of the
regfile.

> 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.

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