[Vm-dev] context change versus primitive failure return value (was: FFI exception failure support on Win64 (Win32 also?))

[John McIntosh]

The slang inliner logic had  a tiny bit of magic in it I added to help it fold the entire GC mark sweep logic into a single c routine and ensure all working variables became local variables to avoid a single or double reference to variables in the interp.c file or to the struct. This made a huge impact on gc times on 68K machines. 

Sent from my iPhone

> On Aug 30, 2018, at 17:57, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
>> On Thu, Aug 30, 2018 at 09:22 Ben Coman <btc at openinworld.com> wrote:
> 
>>  
>>> On Wed, 29 Aug 2018 at 11:08, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> 
>>> The Slang translator and the interpreter code collaborate to inline much of the interpreter, including every method beginning with internal, into the interpret routine in which localFP localSP and localIP are declared, hence allowing a C compiler to assign these variables to registers. 
>> 
>> Ahhh. Maybe I finally get what "internal" means.
> 
> Dan Ingalls described the secret recipe to achieve high performance in a dynamic language as the Art of Cheating Without Getting Caught.
> 
> That's what the "internal" vs "external" is about. To external code, everything looks like expected - e.g.  when you inspect a context object, its stack has all the temp objects and it's instruction pointer is right past the last bytecode it executed, just like the Blue Book describes.
> 
> But in order to get higher performance, even the plain interpreter cheats, the stack interpreter a lot more, and Cog / Spur does unmentionable things.
> 
> To avoid getting caught (by the image or by primitives that are blissfully unaware of the amount of cheating going on) the internal state gets externalized at strategic points to preserve the illusion of order. Nothing to see here, move on.
> 
>> That sounds like each Context has its own instructionPointer, but I didn't think that was so 
> 
> That's exactly what happens. The VM has an active context, and each context has an instruction pointer for the next bytecode, as well as a stack pointer into its own little stack  for values (not for return addresses). Each send creates a new context object which 
> is linked to its sender via the "sender" inst var.  This linked list is the equivalent of a call stack in other languages. 
> 
> And the cool thing is you can inspect all of that in the image. The even cooler thing is that you can manipulate the context objects, like switching out the sender to a completely different context (that's how co-routines work in e.g. a Squeak Generator). The coolest thing is that ever since the StackVM, there is something completely different going on behind the scenes that's much more performant, while still maintaining all the features.
> 
> HTH
> 
> - Bert -
> -- 
> -- 
> Dr. Bert Freudenberg
> 7275 Franklin Avenue #210
> Los Angeles CA 90046
> +1 (818) 482-3991
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180830/7fac6b14/attachment-0001.html>