[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 #57 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #52)
> It seems to me that, as long as:
> 
> 1) we rigorously stick to vector (SVP64, SUBVL) load, stores and operations
> on vector registers,
> 2) stick to predication to access its sub-elements,
> 3) do not use non-SVP64 instructions on register previously used as vectors
> and vice-versa,
> 4) do not change SUBVL on the same vector register
> 
> Then, the "endianess of the register file", and "VL indexing direction"
> should become totally transparent (architecturally invisible).

right.  it occurred to me to point out rhat it is perfectly reasonable for the
compiler to make these restrictions/assumptions in order to simplify the
implementation.

then at a later date optimisations may be applied once the (suboptimal) core is
understood.

however to limit the hardware so that is incapable of supporting the above
flexibility, this does not necessarily follow.

here is a really useful discussion about x86 SIMD:

https://stackoverflow.com/questions/24045102/how-does-endianness-work-with-simd-registers

the contributors conclude that x86 SIMD registers have an "implicit endianness"
and that endianness is LE.

by copying the industry standard conventions it is easy to follow what gcc does
for those architectures and do the same thing.

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