[Vm-dev] Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)
eliot.miranda at gmail.com
Sat Nov 22 16:12:01 UTC 2014
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
> 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
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...
More information about the Vm-dev