[Vm-dev] urgent info required on Slang's shift treatment...
John M McIntosh
johnmci at smalltalkconsulting.com
Tue Mar 3 19:58:53 UTC 2009
Er, well the shift left/right assembler operations are signed or
unsigned, but TYPED languages usually figure out which one to use
based on the type of the operators.
But since Smalltalk is type-less,
What if you code up a unsigned shift operator so there is no question
that you want to do unsigned shifting, which also makes the SLANG
coder just a bit more aware he has a choice to make, casting is ok,
but people forget. Also I can do senders of, then later wonder why am
I not doing that here/there?
Having been bitten by signed shifting issues in the past, I can agree
it's unpleasant.
PS I note we have methods to do unsigned compare logic when dealing
with oop address so that *we* know we are doing something special,
since people
just couldn't manage the casts correctly.
On 3-Mar-09, at 11:50 AM, Eliot Miranda wrote:
> 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.
--
=
=
=
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
More information about the Vm-dev
mailing list