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

[David T. Lewis]

On Thu, Aug 30, 2018 at 09:59:16AM -0700, tim Rowledge wrote:
>  
> I can answer that at least in part - history.
> 
> > On 2018-08-30, at 9:22 AM, Ben Coman <btc at openinworld.com> wrote:
> > 
> > Now a naive question, since as a 13,000 line function its a bit hard to absorb intepret()...
> > why inline by direct code  generation   rather than as using the "inline" directive on individually generated functions ??
> 
> Remember that the basics of this code are not much changed since 1994/5/6 and that the original code was very much Mac oriented. The Mac C compiler of the day didn't really do the inlining thing very well (it's too long ago to remember if many compilers in general use did!) and so a text based approach was used. It literally did simple text substitution and similar hacks. Because it became an essential element of the VM code in that far off time we even got to the point (several times, probably) where *not* doing the inlining run(s) produced code that wouldn't compile. To tell the truth, I have no idea if that is the current state; bursts of hard work over the years has fixed it at least once.
> 

I can add from my own experience that the Slang inliner is very effective
in practice. I was truly amazed to find out how good it is.

Consider the memory access macros (sqMemoryAccess.h). These basically serve
to inline the very lowest level (and hence performance critical) functions
of the VM. When I replaced those macros with equivalent Smalltalk methods
(see the MemoryAccess package in VMMaker), and relied on the inliner to
unwind them, the result was a VM with performance that was, as nearly as
I could tell, the same as the performance of the same VM with traditional
cpp macros.

Think about what that really means. You can write very low level code in
Smalltalk, and rely on the code generator and Slang inliner to spit out
very high performance code. Forget about trying to read the generated C
output, and forget about trying to figure out what those clever macros
are really doing. You can work directly in Smalltalk, no indecipherable
C preprocessor gunk, no compiler directives, no inlined macros. Just
Smalltalk, and the results are outstanding.

Oh, and one more thing. Just try running your VM under gdb to debug it
if you are depending on all those compiler optimizations. Forget it. But
use your Smalltalk tools, write in Smalltalk, translate to C in Smalltalk,
and inline in Smalltalk. Now you can turn off all that compiler optimization
and run even the lowest level memory access code under a debugger, line
by generated line of C source code. Wonderful.

That does not mean that compiler optimizers and directives do not matter.
They do. But do not underestimate the Slang inliner, it is very good.

> An interesting question to answer would be whether current general compilers actually do a good job with inlining. My last experiments were before I moved to Canada in '04, so very out of date, but IIRC it seemed things got slower back then.
> 

It would be interesting to know the answer to this. My guess is that
the results would be at best similar to the Slang inliner. But to me
this falls into the category of great things for somebody else to spend
time on ;-)


> It *should* be the better solution, logically. Compilers are meant to be better at this than us meatbags. If you, or anybody, can find a way to make the considerable time to work on it then we could find out and hopefully benefit. 
> 

Actually, I do not think that it would be better. We meatbags need to
be able to run things under a debugger from time to time, and you simply
cannot do that with a big C program that depends heavily on C compiler
inlining.

Dave