sorry, wrong list.  Will do it right in future.  Mostly.


---------- Forwarded message ----------
From: Chris Cunningham <>
Date: Fri, Aug 21, 2015 at 4:16 PM
Subject: Re: [squeak-dev] Questionable comment
To: The general-purpose Squeak developers list <>

Hi Eliot,

On Thu, Aug 20, 2015 at 9:25 PM, Eliot Miranda <> wrote:
Hi Chris,

On Wed, Aug 19, 2015 at 1:06 PM, Chris Cunningham <> wrote:
well, not questionable - bad.

(in ByteArray)

long64At: index
"Answer a 64-bit integer in Smalltalk order (little-endian)."
| n1 n2 |
n1 := self unsignedLongAt: index bigEndian: true.
n2 := self unsignedLongAt: index+4 bigEndian: true.

These are obviously bigEndian now, nto litte-endian.

Does this mean Smalltalk order (or now Squeak order) has changed?

This is not for general purpose.  The method is part of VMMaker.  Let's take it to vm-dev. 
It's a simple mistake.  If you look at long64At:put: you'll see the comment is correct:

Yes.  I had loaded the VMMaker to look at the ARM jit code (I'm working on an ARM simulator - fun project), and then forgot I had it loaded.  then later, I needed to pull 64-bit integers out of a structure (while writing a KAFKA interface) and stumbled on this.  I think a generalized 64 bit put/access would be useful, and maybe even a general 128 bit too (although I have no need for it at this time).
long64At: index put: val
"I store 64-bit integers in Smalltalk (little-endian) order."
self unsignedLongAt: index put: (val bitAnd: 16rFFFFFFFF) bigEndian: false.
self unsignedLongAt: index+4 put: (val bitShift: -32) bigEndian: false.

I'm now confused.  Not only is the comment wrong, but it looks like the code is wrong.  The get (#long64At:) is actually getting the 64-bit integer in big-endian order (as witnessed by the two sub-calls, too), while the put it truly doing it in little-endian format.

Or am I missing something?

Thanks for finding this!


best, Eliot