[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>
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
-------------- 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