[Vm-dev] InterpreterSimulator
Florin Mateoc
florin.mateoc at gmail.com
Thu Mar 10 18:06:55 UTC 2016
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
More information about the Vm-dev
mailing list