[Vm-dev] InterpreterSimulator

[Florin Mateoc]

On 3/11/2016 8:28 AM, David T. Lewis wrote:
>  
> On Fri, Mar 11, 2016 at 12:04:22AM -0800, Eliot Miranda wrote:
>> 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. 
>>
> You may want to look at package MemoryAccess in the VMMaker repository. I
> have not integrated into the oscog branch, but that could probably be done
> without too much work.
>
> This is an implementation of the sqMemoryAccess.h macros written entirely
> in slang. That means that there is no hidden CPP magic. It is written entirely
> in Smalltalk, and the "simulated" macros are what actually gets translated
> to C. With full inlining, performance is about the same as the CPP macros
> (or at least it was the last time I checked it).
>
> I wrote the package when was working out the 32/64 bit image and host
> combinations for VMM trunk. I was finding the CPP macros rather confusing,
> so it helped be able to work with them in Smalltalk rather than try to
> guess what the macros were going to do.
>
> Dave
>
>

Thanks guys, this gets closer and closer to what I am trying to understand: how good is the match between the simulation
and the translated version and where does it possibly break down?

I had this idea that, since translation necessarily works with a frozen and closed-world assumption, plus there is no
real compile-time pressure, this could be used to translate almost normal Smalltalk instead of Slang and thus
potentially bring even the static VM development to the masses, as a complement to Sista. But of course, if the
simulation is only a best-efforts approximation, this may not work very well.

In addition to the general question above, to help me correct some of my misunderstandings/intuitions, which are solely
based on reading this relatively obscure code, can you please elucidate a couple of mysteries for me?

1. Was this fetchLong64: bug a V3 VM bug as well or just a simulation bug?
2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian?
3. Why do we have both primitives above? They both seem used, but why do some primitives use the first one, coupled with
separate calls for sign, instead of just using the signed version (see primitiveAddLargeIntegers)?

Florin