[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