[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 #97 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #96)
> (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.

Well, all the above would be resolved if we treated scalar arguments as
referring to the whole register, not just one element in a register, as I
proposed (and originally assumed was the case). Scalar here means register
field marked scalar and subvl=1, it depends *only* on the bits in the svp64
prefix, not on VL or mask or anything else that's dynamically adjustable.

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