[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1056

--- Comment #40 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #9)

> Is it possible to request saturating arithmetic with the SVP64 prefix on an
> addi instruction? 

yes.  and on logical (ori). we likely need a different meaning for that.

> If so then that would certainly count as a fundamental
> change to the operation being performed.

post-analysis.

(In reply to Paul Mackerras from comment #22)

> What about saturating arithmetic?

caveat: i simply haven't had time yet to even implement saturation
in the Simulator (ISACaller) - answer: i do not consider this to
be *modification* (strictly: "modification of the pseudocode")

> Could the instruction in fact do nothing, because of predication?

indeed it could!

   for i in range(VL):
       if not predicate[i]: continue
       GPR(RT+i) = GPR(RA+i) + GPR(RB+i)

note that the *pseudocode* - the actual add - is *not* modified.
that's what i mean "the scalar instruction is not modified).

now, it *may* be the case that we have to over-ride the meaning
of the "+" operator to make it possible to detect that overflow
occurred, but in the case of add in the Power ISA spec, well...
that's done anyway: it's called the "carry" flag XER.CA

now, in *hardware* that means that (quoting Mitch Alsup from
comp.arch about 3 weeks ago) you end up if you want to keep to
a single pipeline you get about a 3-5% reduction in top clock
speed, because (and the HW engineers having done XER.CA will
know about this) the overflow flag needs to go into a MUX-bank
selecting

    "all 1s if XER.CA is set" or
    "the result if XER.CA is clear"

and that MUX-bank - at the end of the add-cascade - gives about
a 3-5% increase in gate-chain-count

(a workaround is a 2-stage pipeline)

but - and this is the key - i still *do not* consider "Saturation"
to be an ACTUAL modification of the INSTRUCTION.  the Pseudocode
does NOT change.

-- 
You are receiving this mail because:
You are on the CC list for the bug.