[Libre-soc-dev] new svp64 page

[Luke Kenneth Casson Leighton]

On Thu, Dec 10, 2020 at 3:36 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> Couldn't we just use the already existing VSX instructions for some of
> that and just SV-ify them, where the SV prefix just takes the base
> operation:

second thoughts: if you think it through, saturation [clamping - which
is res = max(-NNN, (min(+NNN, src))] is a post-analysis phase that,
like CR0 / XER post-analysis, can be added here:
   https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/common_output_stage.py;hb=HEAD

and engaged at the CSV level (which is the Micro-Coded ops) just like
carry-in=0/1/XER.CR and so on.

you then have two options:

1) SPR to set clamp/sat mode
2) one maybe two SV Prefix bits that set the clamp/sat mode

(1) is hidden state like MSR BE/LE and consequently should probably
*be* in the MSR... except this gets awkward on changes (requires
instruction stalling, or complex interactions with the OoO issue
engine)

(2) is explicit state at the instruction level, context is passed
through to where it's needed: very very simple.

if you think in those terms there *is* no need for VSX operations or
for over-riding them with a VSX encoding, and consequently we can use
the entirety of the VSX space for alternative instructions... and this
is the important bit... *without having to do a brownfield encoding*.

it's also a hell of a lot simpler to think about:  it's a
post-processing phase, applied to everything arithmetic, and... err..
that's it.

src.qword[0] <- VR[VRA]
src.qword[1] <- VR[VRB]
do i = 0 to 3
    VR[VRT].word[i] <- Chop( Clamp( EXTS( src.dword[i]), -231,
231-1 ), 32 )
end

this is mr, twin-predicated (both predicates set to "off") with dest
elwidth override set to 32, and "clamp/sat" enabled.

as in: it's *mr* (ok ok addi r1, r2, 0).  there's no *need* for a
special version of VSX-overriding.

i do get it, jacob: i just don't like the idea of (a) leaving a
sparsely-populated brownfield encoding of the VSX area when SV-P64
tagged (b) having to explain this to IBM (c) giving the impression
that we think VSX should continue to exist (d) losing the opportunity
to re-use the VSX-allocated major opcodes for something cleaner.

l.