[Vm-dev] Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)

Eliot Miranda eliot.miranda at gmail.com
Sat Nov 22 16:12:01 UTC 2014

Hi Bert,

On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <bert at freudenbergs.de>

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141122/b950e813/attachment.htm

More information about the Vm-dev mailing list