[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 #59 from Paul Mackerras <paulus at ozlabs.org> ---
(In reply to Luke Kenneth Casson Leighton from comment #52)
> (In reply to Paul Mackerras from comment #42)
> > (In reply to Luke Kenneth Casson Leighton from comment #40)
> > 
> > > 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.
> > 
> > I disagree. A saturating addition is not the same as a normal addition.
> 
> it becomes:
> 
>    temp <- [0]*(XLEN+1)
>    ra   <-  0b0 || (RA)
>    rb   <-  0b0 || (RB)
>    temp <- ra + rb
>    if temp[0] then RT <- [1]*XLEN
>    else            RT <- temp[1:XLEN]
> 
> which is, right up to the test temp[0], identical to add

The RTL is different from a non-saturating add, so you have changed the
function of the instruction.

> and when addeo
> is examined i think you'll agree it is "if XER.CA then saturate"

No, I don't agree. It could be "if addc would set XER.CA then saturate" but we
could be doing add or addi.

> > If
> > you don't change the RTL then it would no longer accurately describe the
> > operation being performed, since the meaning of "+" is defined in section
> > 1.3.4 to be two's complement addition. 
> 
> the sane thing to do is override that.  it already is (sort-of).
> XER.CA is *not* in the actual RTL, only described in english language.
> 
> (i.e. the precedent of doing "a little bit more than what the RTL says"
>  is already set).

As far as things that aren't mentioned in the RTL, yes. Can you point to any
place where the RTL says a particular value is stored in a register but in fact
a different value is stored?

> > You either need to replace the "+" in
> > the RTL with some notation for a saturating addition, or you need to add a
> > statement that calls some kind of saturate() function on the result before
> > writing it to the destination GPR.
> 
> at which point we have identical-RTL-except-the-call-to-Saturate
> to maintain, QTY hundreds of instructions.
> 
> that ain't happenin :)

It seems to me that we don't yet have a good solution to this problem of how to
describe what vectorization does to existing scalar instructions, and it may
take a while to come up with something that satisfies all parties.

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