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

Chris Muller asqueaker at gmail.com
Sat Nov 22 20:26:33 UTC 2014


On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> 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.

Berts made more sense to me simply because signed support
negatives(-), where unsigned only support positive(+)..


More information about the Vm-dev mailing list