[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 #96 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #95)
> (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.

the problems start when trying to interact between the two.  elwidth!=default
has now become "special", meaning that elwidth=default is left in the wrong
byte order when compared to elwidth!=default.

that forces a "mess" of opcodes to perform unnecessary copying of data from
scalar regs to vector regs... which will still *fail* on the 64 bit case
because elwidth=default VL=1 copying of scalar into vector has no "meaning" -
no continuation - of the byteswapping.

i.e. to get the *64* bit scalars to be copied into vectors in the correct order
is simply not possible and would require a "tag".

this is what i meant by that SV "identity behaviour" has been violated.

that being unacceptable, it will not work, and consequently requires explicit
control over the bytereversing from the ISA, not as an implicit "special"
violation.

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