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

[Eliot Miranda]

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:


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...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090303/37c45c6f/attachment.htm