<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 9, 2016 at 5:27 PM, Florin Mateoc <span dir="ltr"><<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 3/9/2016 8:23 PM, Eliot Miranda wrote:<br>
><br>
> Hi Florin,<br>
><br>
> I believe the correct fix is for ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8. I'll commit asap (which is once I have 64-bit small float tagging converted). But your fix should keep you going until then.<br>
><br>
> _,,,^..^,,,_ (phone)<br>
<br>
<br>
<br>
</span>Hi Eliot,<br>
<br>
I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :))<br></blockquote><div><br></div><div>Because in V3 any object occupies some number of 32-bit words, zero padded. So a 5 byte large integer is actually a 4 byte header followed by an 8 byte unit whose most significant 3 bytes are always zero. In Spur, any object occupies some number of 8-byte words, so a 5 byte integer has an 8 byte header followed by an 8 byte unit, but a 9 byte integer occupies 24 bytes (8 byte header, 16 bytes data).</div><div><br></div><div>So in V3, fetching 64-bits from a 5 to 8 byte large integer must be done in two reads because objects are only aligned to a 4 byte boundary, but in Spur it can be done in a single 64-bit read because all objects are aligned on an 8 byte boundary.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Florin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
>> On Mar 9, 2016, at 1:53 PM, Florin Mateoc <<a href="mailto:florin.mateoc@gmail.com">florin.mateoc@gmail.com</a>> wrote:<br>
>><br>
>><br>
>>> On 3/9/2016 3:17 PM, Florin Mateoc wrote:<br>
>>> Hi again,<br>
>>><br>
>>> I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even<br>
>>> mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes.<br>
>>> In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption<br>
>>> come from, because it does not seem limited to this method.<br>
>>> Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail.<br>
>>><br>
>>> Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied<br>
>>> and pasted.<br>
>>> For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte<br>
>>> LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to<br>
>>> 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits.<br>
>>><br>
>>> Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and<br>
>>> #positive64BitValueOf: do not take care of the BigEndian case.<br>
>>><br>
>>> Cheers,<br>
>>> Florin<br>
>><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>