[Libre-soc-dev] new svp64 page
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Dec 10 16:27:33 GMT 2020
On 12/10/20, Lauri Kasanen <cand at gmx.com> wrote:
> On Thu, 10 Dec 2020 15:21:02 +0000
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>> 1) SPR to set clamp/sat mode
>> 2) one maybe two SV Prefix bits that set the clamp/sat mode
> The saturation mode changes often, so it absolutely should not change
> with an instruction.
... and back again. that's 3 instructions where one would do.
so, no to SPRs, i'll make a note.
lauri, jacob, what's your thoughts on using 2 bits for clamping mode?
similar to elwidth:
* 0b00 default (no clamp)
* 0b01 8 bit (sel: -128/127, us:0/255)
* 0b10 16 bit
* 0b11 32 bit
this is *not* the same as elwidth itself, which is the "chop" in VSX
or: another idea:
* extsb, extsh, extsw specify one type of width
* twin predication specifies 2 more (src elwidth, dest elwidth)
* 1 bit says "operation is to be clamped" (not to which range, that's implicit)
then you take the "clamp" range from the extsb/extsh/extsw operation.
* extsb would set the clamp range to -128/127
* extsh to -65536/65535
* extsw to -2^32/2^32-1
this is however even just looking at it like that, it leaves out
add-clamp, mul-clamp etc etc. and because there are no zextu
operations in scalar OpenPOWER...
btw i thought of another reason why not to use VSX with alternative
meanings: huge complexity at the decoder.
SV is very much along the RISC style. 2 bits SUBVL. 2 bits elwidth.
2 bits sat/clamp mode.
if we try to use VSX encodings we need a remapper, "if XO ==
0b101110010 or this or that, clamp_mode = true"
and, in addition, to have similar remappers from VSX op to the
underlying scalar op (add mul etc).
More information about the Libre-soc-dev