[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 #104 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Alexandre Oliva from comment #5)
>
> 
> GCC seems to regard vector types just like arrays, when it comes to memory
> layout, so indexing it operates like indexing arrays.  this does mean,
> however, that loading the vectors above from memory into a scalar 64-bit
> register will land element [0] at opposite ends depending on endianness. 

1) opposite end of what? the 64 bit register? (this does not happen)
or do you mean the entire array?
to consider the whole array to be endian ELEMENTS 7 6 5 4 3 2 1 0 rather
than 0 1 2 3 4 5 6 7 is a completely different matter from
the endianness of the *elements themselves*.

a "reverse gear" bit however has been added to SVP64 which
allows elements to be loaded in reverse order (VL-1 downto 0)

2) by defining the regfile as strictly as the typedef union says, when
considered as a LE system, the order is fixed and easy to understand.

when elwidth=default (64) each element does **NOT** end up in the "wrong"
order at all.  the use of the typedef union shows that the elements are loaded
64 bits, into 64 bit register boundaries.

when elwidth=32, Vectorised LD will load element 0 into the bottom
32 LSBs of the first 64 bit register, and element 1 into the top 32 MSBs of
the first 64 bit register.  if BE mode is enabled, each byte OF THE 32 BIT
QUANTITY will be reversed by the LD operation.

if that was not desired, just use ldbrx instead. that's what ldbrx is for.

following on from there and assuming that the subsequent instructions
are also elwidth=32 then the elements are correctly accessed in exactly
the same element order as when they were inserted by the Vector LD
operation.

if you didn't use Vectorised ldbrx to invert the data then that is your
lookout.

if people want this feature added it has to be properly evaluated and explain
why use of ldbrx and SV REMAP bytereverse mode is not adequate.

however it will be given absolute lowest possible priority unless there is
a compelling reason demonstrated otherwise.

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