[Vm-dev] urgent info required on Slang's shift treatment...
eliot.miranda at gmail.com
Tue Mar 3 21:30:43 UTC 2009
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:
OK, my workaround is as follows. I've previously added the "vmClass" to the
CCodeGenerator, which is non-nil if translating the Interpreter (also
StackInterpreter & CoInterpreter/Cogit). Now the CCodeGenerator asks the
vmClass if non-nil whether to genenrate signed shifts and to default to the
old behaviour. So I can defer fixing all uses elsewhere and just
concentrate on fixing uses in Cog.
> Best regards,
> Igor Stasenko AKA sig.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev