<div dir="ltr"><div>I want to add 3 things about inlining:</div><div>
<div>- 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<br></div>

- then inline is a compiler directive or hint or suggestion, but it is not a mandatory requirement, very much like register</div><div>  So if we want fine control, we can't entirely trust it</div><div>- 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...</div><div><br></div><div>For understanding code, it's better to stick to Smalltalk side and emulating the VM.</div><div>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.<br></div><div>Personnally, slang inlining annoyed me when tracking those compiler warnings, because it generates a lot of noise!<br></div><br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le ven. 31 août 2018 à 03:41, John McIntosh <<a href="mailto:johnmci@smalltalkconsulting.com">johnmci@smalltalkconsulting.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="auto">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. <br><br><div id="m_-5462942604537852761AppleMailSignature">Sent from my iPhone</div><div><br>On Aug 30, 2018, at 17:57, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div>On Thu, Aug 30, 2018 at 09:22 Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, 29 Aug 2018 at 11:08, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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.  </div></div></div></blockquote><div><br></div><div>Ahhh. Maybe I finally get what "internal" means. </div></div></div></div></div></div></div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Dan Ingalls described the secret recipe to achieve high performance in a dynamic language as the Art of Cheating Without Getting Caught.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">But in order to get higher performance, even the plain interpreter cheats, the stack interpreter a lot more, and Cog / Spur does unmentionable things.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>That sounds like each Context has its own instructionPointer, but I didn't think that was so </div></div></div></div></div></div></div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">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 </div><div dir="auto">is linked to its sender via the "sender" inst var.  This linked list is the equivalent of a call stack in other languages. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">HTH</div><div dir="auto"><br></div><div dir="auto">- Bert -</div></div></div>-- <br><div dir="ltr" class="m_-5462942604537852761gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">-- </div><div dir="ltr">Dr. Bert Freudenberg</div><div dir="ltr">7275 Franklin Avenue #210</div><div dir="ltr">Los Angeles CA 90046</div><div dir="ltr"><span style="letter-spacing:0.2px">+1 (818) 482-3991</span><br></div><div dir="ltr"> </div></div></div></div></div></div>
</div></blockquote></div></blockquote></div>