[libre-riscv-dev] spike-sv status and REMAP (RESHAPE) CSRs

[Luke Kenneth Casson Leighton]

ok so i have FLD/FLW implemented, and FADD, with element widths, and
preliminary unit tests confirming that, where tested, they work
according to the spec.  which is really *really* quite comprehensively
difficult to understand, as the width of the operation (S/D/Q) in both
the source *and* destination register is critical and vital
information that has to be taken into account.

i've clarified on the specification that the width of the operation in
both source and destination - a 32-bit FADD or a 32-to-64-bit FMV -
effectively sets the target width that is to be used as a "virtual"
register of "width / elwidth" actual elements.

if, as is done in the RV Base spec, the upper bits are set to 1s or
0s, it would actually be destroying other  "virtual" registers within
that same "real" register.

this does not seem to have any meaning until the RESHAPE CSRs kick in,
where i have just added an "offset" to the reshaping.  now, even with
a scalar redirection, it becomes possible to set an "offset" which,
instead of starting from bit 0 of the "real" register, the access is
offset by N element's worth of bits.

ordinarily this same effect would be achieved by using predication:
the first few elements would be skipped as a result.  however
predication on arithmetic operations only apply en-masse to source
*and* destination registers, whereas the "offsets" can be applied
independently and arbitrarily to up to three specific registers.

the question is, though: should the offset be applied and *then* the
1/2/3D reshaping algorithm be applied, or should the reshaping be
applied and *then* the offset added?  i'm leaning towards the latter
at the moment.

l.