[Libre-soc-dev] new svp64 page

[Luke Kenneth Casson Leighton]

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
ops pseudocode.

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).

l.