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

[Nicolas Cellier]

I want to add 3 things about inlining:
- inline has not been standardized before C99, even though it already
existed in gcc well before; historically; it was not a solution at the time
of original VM writing
- then inline is a compiler directive or hint or suggestion, but it is not
a mandatory requirement, very much like register
  So if we want fine control, we can't entirely trust it
- third, with type inference taking place at slang translation, some
Smalltalk messages might be like generic template derived for different
types, depending on sender, and this specialization happens during slang
inlining. I don't remember if the VM really depends on this feature, but if
so, we couldn't just replace by an inline directive, but should also care
for generating several signatures instead of a single function...

For understanding code, it's better to stick to Smalltalk side and
emulating the VM.
But there are subtle differences between emulated slang and generated C
code, especially for the handling of types, and it is also sometimes
necessary to debug the translation itself (wrt undefined behaviors for
example), in which case compiler warnings are one of the low level
companion tool.
Personnally, slang inlining annoyed me when tracking those compiler
warnings, because it generates a lot of noise!



Le ven. 31 août 2018 à 03:41, John McIntosh <johnmci at smalltalkconsulting.com>
a écrit :

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