[Vm-dev] InterpreterSimulator

[Florin Mateoc]

On 3/11/2016 5:47 PM, Eliot Miranda wrote:


<snip>

> The simulation is pretty close.  The JIT's simulation closer.  This is simply history, plus the fact that debugging a
> JIT is more difficult and therefore more accurate simulation helps.
>  
> But if you're interested in closed world translations you might contact Gerardo Richarte and Xavier Burroni and ask
> them about their JIT work.
>
>     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?
>
>
> Just a simulation bug.  The code generated for the real VM is correct.
>   
>
>     2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian?
>
>
> They don't have to.  Large Integers in Smalltalk are always little endian.  Nicolas Cellier has a prototype that would
> organize then as a sequence of 32-bit words, in which case they would be endian-dependent, but this is problematic
> because in 32-bit systems SmallInteger is only 31 bits, and so accessing the one and only 32-bit word of the large
> integer 16rFFFFFFFF answers that large integer itself.  Further, organizing it as a sequence of 16-bit words doesn't
> help either because 16rFFFF * 16rFFFF overflows 31-bit SmallIntegers. so if one wants to be able to implement large
> integer arithmetic non-primitively in the image using SmallIntegers, 8 bits is the largest convenient unit.
>  
>
>     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)?
>
>
> Some large integer primitives want to interpret the bit patterns in large integers as bit patterns and use
> magnitude64BitValueOf:.  So,e primitives want to interpret the bit patterns in large integers as arithmetic values,
> failing for LargeNegativeInteger, and use positive64BitValueOf:.  Perhaps positive64BitValueOf: is surplus to
> requirements, but it fits with the  existing set. BTW, they are /not/ primitives.  They are run-time support
> functions.  Let's not get confused.
>
>     Florin
>
>
> _,,,^..^,,,_
> best, Eliot

Thank you for the explanations, especially since I know you are very busy.

As for my interest in closed world translations, I am indeed interested and I know it can be done (the type inferencing
and inlining parts), but if I don't have "customers", meaning especially you as Squeak's main vm developer, I won't
spend time on it. It is not a trivial project.

Cheers,
Florin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160311/31e93f92/attachment.htm