[Vm-dev] urgent info required on Slang's shift treatment...

Igor Stasenko siguctua at gmail.com
Tue Mar 3 20:52:14 UTC 2009

2009/3/3 Eliot Miranda <eliot.miranda at gmail.com>:
> On Tue, Mar 3, 2009 at 12:09 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> 2009/3/3 Eliot Miranda <eliot.miranda at gmail.com>:
>> >
>> > Hi All,
>> >     I'm being bitten by Slang's treatment of bitShift: & >>.  In both cases (generateBitShift:on:indent: & generateShiftRight:on:indent:) Slang generates an unsigned shift by explicitly casting the shifted expression to usqInt.  I can understand the benefit of having an unsigned shift.  But there are times when one really needs a signed shift.  Further, the Smalltalk versions of both bitShift: and >> are signed shifts.
>> > Dare I change e.g. generateShiftRight:on:indent: to leave the expression alone and generate either a signed or an unsigned shift based on the variable's declaration?  Or must I live with a maddening cCode: '(signed)' inSmalltalk: [] carbuncle?
>> > E.
>> >
>> I think an easier way would be to add:
>> #<<+    #generateSignedShiftLeft:on:indent:
>> #>>+    #generateSignedShiftRight:on:indent:
>> in #initializeCTranslationDictionary
>> so you can use:
>> a <<+ b
>> or
>> a >>+ b
>> without writing horrible cCode:
> good work-around.  Thanks.

btw, you not alone noticed that :)

I have an incomplete rewrite of code gen.. where i threw away numerous
for common binary operators and replaced them with single:

and when i came to shifts it is also makes me wonder, why an argument
needs to be converted to unsigned one before shiftting..

One thing, that i may guess, that shitfing is used extensively when
dealing with headers..

header := self longAt: oop.

type := header bitAnd: TypeMask >> TypeShift.

and since all 32 bits of header is used for different purposes, it is
better to treat header as an unsigned word for shifting operations.
I don't see any other uses of shifts in VM which could/should need
casting to unsigned.

>> --
>> Best regards,
>> Igor Stasenko AKA sig.

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list