[Vm-dev] InterpreterSimulator

[Eliot Miranda]

Hi Florin,

> On Mar 10, 2016, at 10:54 AM, Florin Mateoc <florin.mateoc at gmail.com> wrote:
> 
>> 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> 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.
> 
> 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:?
> i.e. replacing the hardcoded 8 with BytesPerWord:
> 
>     byteAddress \\ 8 ~= 0 ifTrue: [self unalignedAccessError].

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. 

> 
> Florin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160311/35c01d41/attachment.htm