<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Florin,</div><div><br>On Mar 10, 2016, at 10:54 AM, Florin Mateoc <<a href="mailto:florin.mateoc@gmail.com">florin.mateoc@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 3/10/2016 12:02 PM, Eliot Miranda
wrote:<br>
</div>
<blockquote cite="mid:CAC20JE3fKqOcoOVr2Hwf1wnHzh_ns7MQmJhJExjj_h5_=5h_1A@mail.gmail.com" type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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 moz-do-not-send="true" 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>
</div>
</div>
</div>
</blockquote>
<br>
Since ObjectMemory (in its subclasses) actually already decomposes
long64At: in two 32-bit reads, instead of duplicating the
decomposition in fetchLong64:ofObject: (the caller or long64At:),
shouldn't the fix just be to replace the alignment check within
long64At:?<br>
i.e. replacing the hardcoded 8 with BytesPerWord:<br>
<br>
byteAddress \\ 8 ~= 0 ifTrue: [self unalignedAccessError].<br></div></blockquote><div><br></div>This is where it gets tricky. The implementations of longAt:[put:] et al in the subclasses are only for simulation. The real ones are in platforms/Cross/vm/sqMemoryAccess.h and depend on, or rather are chosen to deal with, the semantics of the actual underlying machine, what its word size, endianness and alignment restrictions are. The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware. Hence removing that alignment check would only be valid on 32-bit machines that allowed unaligned 64-but access, a shrinking set these days that doesn't even include x86 in its sse instructions. <div><br><blockquote type="cite"><div>
<br>
Florin<br>
</div></blockquote></div></body></html>