[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 #52 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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 and when addeo
is examined i think you'll agree it is "if XER.CA then saturate"




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


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


> Look at the RTL for vaddsbs, for instance. It does si8_CLAMP(src1 + src2).
> (The saturation functions are called xxx_CLAMP() in the vector chapter.)

been through the options.  post-analysis *like Rc=1 and XER.SO/CA*
was the sane conclusion, checking that would be v. helpful, bear in
mind i have not got round to implementing Saturate in ISACaller
so everything surrounding saturate is "unconfirmed" at the moment.

(i do NOT allow things to go into the spec without also implementing
 them in the Simlator, ISACaller, including full unit tests.
 Saturate is the very last "big" feature that simply hasn't had time
 to be implemented yet)

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