[Libre-soc-dev] [SVP64] feedback needed - Pack/Unpack (vpack/vunpack)

lkcl luke.leighton at gmail.com
Sat Aug 13 03:04:56 BST 2022


> how about requiring dest elwidth == src elwidth when
> pack/unpack is enabled, allowing you to use 1 bit for
> enabling pack/unpack, and the now available dest elwidth
> field for selecting what kind of pack/unpack you want?
> this allows it to fit in 9 bits.
>Jacob

as i was writing i was just thinking that.  the issue is that you
end up *removing* elwidth overrides from operations, instead
of damaging the range of regs (r0..r63) now you damage
src/dest overrides.

remember these operations are going to be used frequently
with Pack/Unpack *not* set.

so for when Pack/Unpack is *not* used, you still have to suffer
the limitation caused by sacrificing elwidth overrides instead.
and we are talking pretty basic and fundamental data move
ops, here: GPR mv, FPR mv, LD/ST-immediate.

not being able to do narrowing/widening data transfers on those
3 fundamental categories of operation, that's... quite a serious
decision.

it's really tricky in other words!

a workaround is to have duplicate ops (marking sv.xori as PU
effectively gets round the problem) but not on FP or CRs.

if there was a 2nd FP mv instruction somewhere it could be
used.

l.


More information about the Libre-soc-dev mailing list