[Vm-dev] urgent info required on Slang's shift treatment...
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
>> 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.
Igor Stasenko AKA sig.
More information about the Vm-dev