[Vm-dev] 64 bits VM: how sign extension may strike

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Oct 25 16:44:16 UTC 2015


Hi,
one potential problem with 64 bits is for example the (usqInt) cast when
shifting >>

Example:

    (((usqInt) sourceWord) >> 24)

will correctly extract the 8 high bit is sourceWord is an unsigned int.
if source word is an declared as int, then we will get a sign extension

(usqInt) 0xF7654321 -> 0xFFFFFFFFF7654321UL

If with don't bitAnd: 0xFF the result, it ain't gonna meet our expectations.

That rarely happen that we declare int, by default it's rather sqInt.
But things like
   sqInt foo = long32At( oop , index );
will also perform a sign extension...
Even if (((usqInt) foo) >>24) doesn't perform the sign extension by itself,
we get the same behaviour at the end.

If we carefully place a 'unsigned int' type hint in a method, it is thus
vital that this type be preserved with inlining.

When I analyze the code, most long32At could in fact be replaced with
unsignedLong32At. If tthat didn't make much difference in 32 bits, it seems
more vital to me with 64 bits sqInt...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151025/85922c09/attachment.htm


More information about the Vm-dev mailing list