Hi Eliot,

On Thu, Aug 20, 2015 at 9:25 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Chris,
>
> On Wed, Aug 19, 2015 at 1:06 PM, Chris Cunningham <cunningham.cb at gmail.com
> > 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.
> ^val
>
> 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?

-cbc


> Thanks for finding this!
>
>
>
>> -cbc
>>
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150821/2c2a4aea/attachment.htm