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

lkcl luke.leighton at gmail.com
Sat Aug 13 11:02:42 BST 2022


> pack/unpack-enable field   destelwidth field
> 0 00 -- no pack/unpack, dest elwidth = 00
...

on the other hand, if a bit in the *RM.Mode* can be found to
indicate whether the EW bits are to be interpreted as PU, then
that would do the trick.

ha.

and i think, looking at each of CRops, normal/arithmetic, LDST
tables, there is one bit (just about) spare in each.

LDST i just removed shiftmode

Arithmetic can lose ReverseGear on Subvector Mode

    00	1	SVM RG	subvector reduce mode, SUBVL>1

becomes

    00	1	SVM 0	subvector reduce mode, SUBVL>1
    00	1	SVM 1	subvector PackUnpack mode

CRops there is almost an entire column available but ahh wait,
https://libre-soc.org/openpower/sv/cr_ops/

that is using bits 6-7 already, no it's ok, can use bits 4-5
https://libre-soc.org/openpower/sv/svp64/#index7h1

drat bits 4-5 are for RT or RA elwidth overrides when copying
to/from CR and CR Fields... but hang on let's interpret that as
meaningless, i.e. "you can't override EW for mtcr and mfcr",
that just leaves the crweird ops
https://libre-soc.org/openpower/sv/cr_int_predication/

for these it is only those involving CRfields to GPRs that
matter, but i think it reasonable to say that attempting to
do pack/unpack on subvectors of such operations is
completely mad.  they are weird enough already.

in all i think we're good.  it's dodgy as hell but i think doable,
and the really nice thing is, because it is in RM.MODE, it is
uniform which is as it should be.

l.




More information about the Libre-soc-dev mailing list