[Libre-soc-isa] [Bug 968] document shift-and-add instruction

[bugzilla-daemon at libre-soc.org]

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

--- Comment #20 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Andrey Miroshnikov from comment #18)
> (In reply to Luke Kenneth Casson Leighton from comment #14)
> > no it does not.
> > 
> > > There is no explicit sign-extension in the pseudocode.
> > 
> > correct.  if the desired behaviour was to perform a signed 32bit add
> > then not only would EXTS be used, the instruction would be called "shaddsw"
> > (or sigh shaddws)
> 
> Then why did you give me an example with SIGNEXTEND and ZEROEXTEND, if they
> are not relevant?

because the question you asked was, "why is it not sign-extended".
the answer to that involves creating two sets of pseudocode, one
sign-extending one not-sign-extending, then putting in an example
value and noticing that the sign-extending one gives the WRONG result.

sign-extending:

   RB=0x0000_0000_8000_000
   SIGNEXTEND(RB) -->
   0xFFFF_FFFF_8000_0000

this is the WRONG thing to do.  shadduw is SPECIFICALLY DESIGNED
to NOT perform this signextension on RB.


> A lot of my confusion comes from the naming of these two instructions.
> 
> Is there a good reason as to why shadduw uses "uw" (Unsigned Word)?

because it explicitly makes clear that RB is **NOT** to be sign-extended
before the addition.

> Since both shadd and shadduw are unsigned, you're putting emphasis on the
> shadduw being unsigned.
> Of course shadduw also deals with a "word" so unsigned is probably necessary
> here.

yes.

> While shadd does not imply the operation deals with unsigned or signed
> integers.

yes. because when both RA and RB are 64-bit, there *is* no difference.

sign-extension only matters when one of the two numbers is a DIFFERENT
bitwidth.

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