[Libre-soc-isa] [Bug 560] big-endian little-endian SV regfile layout idea
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Wed Dec 30 23:55:52 GMT 2020
--- 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.
> 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
now the underlying order *does* matter.
you set b to 0x55 does that mean that w 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
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 array...
> 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
> 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
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
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
> 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.
More information about the Libre-SOC-ISA