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...
vm-dev@lists.squeakfoundation.org