[Vm-dev] InterpreterSimulator

[Eliot Miranda]

> On Mar 11, 2016, at 5:09 PM, Florin Mateoc <florin.mateoc at gmail.com> wrote:
> 
> 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.

Then maybe we can pull you into some Sista work.  Eventually it will make sense to work in closed world translations, especially if, as Gerardo and Xavier did, one wants to write the VM in pure Smalltalk and have it translate itself (bootstrap itself) to external code.  But that may be quite an effort and be something we can collaborate on.  But right now the focus is on making what else have now fast and complete.  The "perfect" solution can wait until we can afford the opportunity cost.

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