<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 &lt;<a href="mailto:florin.mateoc@gmail.com">florin.mateoc@gmail.com</a>&gt; 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">&lt;<a moz-do-not-send="true" href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>&gt;</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>
                &gt;<br>
                &gt; Hi Florin,<br>
                &gt;<br>
                &gt;&nbsp; &nbsp; I believe the correct fix is for&nbsp; ObjectMemory
                needs to decompose fetchLong64:ofObject: into two 32-but
                reads unless BytesPerWord = 8.&nbsp; I'll commit asap (which
                is once I have 64-bit small float tagging converted).&nbsp;
                But your fix should&nbsp; keep you going until then.<br>
                &gt;<br>
                &gt; _,,,^..^,,,_ (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.&nbsp; 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.&nbsp; 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>
    &nbsp;&nbsp;&nbsp; byteAddress \\ 8 ~= 0 ifTrue: [self unalignedAccessError].<br></div></blockquote><div><br></div>This is where it gets tricky. &nbsp;The implementations of longAt:[put:] et al in the subclasses are only for simulation. &nbsp;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. &nbsp;The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware. &nbsp;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.&nbsp;<div><br><blockquote type="cite"><div>
    <br>
    Florin<br>
  

</div></blockquote></div></body></html>