[Vm-dev] Signed/unsigned shifting

[Ben Coman]

Eliot Miranda wrote:
>  
> 
> 
> ------------------------------------------------------------------------
> 
> Hi Bert,
> 
> On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <bert at freudenbergs.de 
> <mailto:bert at freudenbergs.de>> wrote:
> 
>      
>     On 21.11.2014, at 23:01, Eliot Miranda uploaded
>     VMMaker.oscog-eem.950.mcz
>      >
>      > Introduce >>> as an explicitly signed shift.
> 
>     Ugh, can we pick something else, please? It's really confusing. In
>     various languages (notably Java and JavaScript), >> is signed and
>      >>> unsigned. I don't know any language that has both operators and
>     the meaning reversed.
> 
> 
> This is confused because of history.  What I'd like is to use >> as a 
> signed shift (because that's what it is) and >>> as an unsigned shift.  
> And I'd like to change bitShift: to generate signed shifts and introduce 
> unsignedBitShift: and ditch signedBitShift:.  But that means changing 
> all uses of >> in VMMaker.  This would be my preferred solution but I 
> think its *really* important that if we go this route we change 
> VMMaker.oscog, VMMaker and VMMakerJS at the same time.  Can we 
> synchronise this?
> 
>  
> 
> 
>     And >> still means signed or unsigned depending on context. Not nice
>     at all.
> 
> 
> Right.  And there's the signedBitShift: bogosity too.
>  
> 
> 
>     How about ...
> 
>             >> signed/unsigned depending on type (what we have now)
>             >>+ force unsigned shift
>             >>- force signed shift
> 
> 
> That's funny.  For me the + screams signed.  So I would accept
> 
>         >> signed/unsigned depending on type (what we have now)
>         >>+ force signed shift
>         >>- force unsigned shift
> 
> But I don't think you're right about >> being context dependent.  At 
> least in VMMaker.oscog >> is always unsigned.  The change I made to 
> generation was to not coerce a 64-bit receiver to 32-bits, but I didn't 
> change the signedness.
> 
> -- 
> best,
> Eliot

The use of both + and - still leaves room for ambiguity.  How about...
 >>> force unsigned
 >>+ force signed

cheers -ben