[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 #95 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #94)
> thoughts on whether this is practical (at the ISA level)
> 
> * LD 32 bit (lw) brings in data, scalar
> * scalar is supposed to be identical to vector of len VL=1
> * LD behaviour CHANGES to "do not do byteswap, this is now ALU/regfiles job"
> * unfortunately all v3.0B is 64 bit not 8, 16 or 32.
> 
> which means that to "work" there would need to be a LD width "tag"
> propagated to each regfile entry, just like in the Mill Architecture.

a tag is not actually needed: lw with elwidth=default does normal load
byteswapping and sign/zero extension to 64-bits then byteswaps the 64-bit
result to the cpu's current endian, making the effective register value
identical to the OpenPower expected value.

lw with elwidth=32 does normal load byteswapping, then byteswaps the 32-bit
value to the cpu's current endian, writing the result to the first/current
(depending on scalar/vector on dest reg) vector element. This all is equivalent
to copying 32-bits to the correct vector element in the dest reg in the cpu's
current endian.

I do not see how either of those instructions would require a register tag.

> clearly that is unworkable (too radical a departure from OpenPOWER)

I disagree, it matches how VSX works: where a scalar float load single will
convert to 64-bits and store that in the register in the cpu's current endian.
a vsx scalar float load 32-bit will load 32-bits and write to the first vector
element in the cpu's current endian.
a SIMD vector float load 32-bit will load 4 32-bit values in successive memory
locations, writing them to the first through 4th vector element in the cpu's
current endian.

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