[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 #12 from Alexandre Oliva <oliva at libre-soc.org> ---
hmm...  jacob wrote:

> basically, it will make the in-memory layout of vector types identical to the in-register layout.

which is at odds with what luke wrote:

> WE ASSUME LE SRAM ON REGFILE BECAUSE OTHERWISE IT IS TOTAL HELL

now, I don't know what LE SRAM really means.  to me, the register file has no
endianness whatsoever; 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.  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.  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.  the
relevant concept is significance (from least to most significant), not lowest
or highest address, which applies to memory order.

having expressed this distinction on how I reason, hopefully it will be clear
why your response is not an answer to my question.  you don't get down to the
memory addresses, you just number the bytes of the registers, which might be
ordered by significance, 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.

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


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

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