[Vm-dev] InterpreterSimulator

[Florin Mateoc]

On 3/10/2016 12:02 PM, Eliot Miranda wrote:
>  
>
>
>
>
> On Wed, Mar 9, 2016 at 5:27 PM, Florin Mateoc <florin.mateoc at gmail.com <mailto:florin.mateoc at gmail.com>> wrote:
>
>
>     On 3/9/2016 8:23 PM, Eliot Miranda wrote:
>     >
>     > Hi Florin,
>     >
>     >    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.
>     >
>     > _,,,^..^,,,_ (phone)
>
>
>
>     Hi Eliot,
>
>     I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :))
>
>
> 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).
>
> 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.

Thank you, that makes perfect sense

Florin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160310/fd801c54/attachment-0001.htm