<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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;    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>
                &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.  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.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Thank you, that makes perfect sense<br>
    <br>
    Florin<br>
  </body>
</html>