[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 #15 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Alexandre Oliva from comment #12)
> 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.

byte order *is* significant in registers precisely because we can treat them as
an indexed vector of bytes by using vector u8 instructions. having that vector
of bytes match the vector of bytes in memory is important for performance and
consistency, since otherwise we will have to insert tons of byte-swap
instructions for memory-order bitcasting that would otherwise be totally
unneeded.
> 
> 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.

As far as I know, the plan is for scalar subvl=1 sources and destinations to
read and write full registers, not just the first or last byte/u16/u32/u64.
This is similar to how divwu writes the whole dest register even though the
result is only 32-bits.

for vector registers and/or subvl>1, they use only the part of the registers
that correspond to indexes<VL.

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