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

Bert Freudenberg bert at freudenbergs.de
Fri Aug 31 00:57:12 UTC 2018


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/b19895d2/attachment.html>


More information about the Vm-dev mailing list