[Q][VM][ENH][RFH][COMP] Request For Help : CompilerPlugin

Hans-Martin Mosner hmm at heeg.de
Thu Apr 4 21:24:23 UTC 2002


Matthias.Klein at tlc.de wrote:

> Hmm Compiling Smalltalk to C/C++?
>
> We did this a couple auf years ago (around 1988/89). It was for an autonomous
> robot controller to be programmed in Smalltalk. It turned out to be a bad idea.
>
> Ok, we really got it runnig. We could compile our 'headless' image to
> a working executable and run it together  with the vm and byte compiled
> smalltalk. But it was not worth the effort.  Just a few of our experiences:
>
> - We did never see more than a fourfold increase in speed on the
> average. This was mainly due to message dispatch, as smalltalk
> methods tend to be short. (Message dispatch cannot be made faster
> by compilation)
>
> - Garbage Collection: Somehow, the garbage collector must know what is on
> C's stack. This uglifies the generated code, which is already ugly enough.
>
> - Debugging: don't remind me of that. It was horrible, especially if we
> had to debug mixed native and bytecode
>
> These are just a few of the points on the downside. There were many more,
> and none on the upside, as far as i remember :-))

Claus Gittinger of Smalltalk/X fame could probably provide some more data points.
I think he's quite happy with the results he gets.
But in general I think that compiling to C would gain little unless you do really
serious type inference and inlining, and then you get code bloat. Either way,
you've got to loose. I think that the PARC or ParcPlace people once did an
analysis which showed that translating bytecode to native code and executing that
could be faster than generating C statically, due to better cache behavior. In
there case, cache was main memory and large apps would have needed paging, while
today cache is, well, cache, and main memory is normal RAM. But I still think that
a bytecode translator and native method cache which fit into the L2 cache of the
machine can perform quite well against bloated code thrashing the instruction
cache...

> When the project was finally stopped (the contractor realized that robots were
> "totally out of his product portfolio", they normally did chemical sensors), we
> had completely redesigned it, but now lacked the funds to implement that.
> Some of our ideas where:
>
> -'pageable image': load methods/objects on demand (and swap them out
> due to some criterion as lru)

See the Smalltalk-80 historical literature (green book). There's almost nothing
that these guys didn't think about *and implement* years before 'mainstream' got
the idea and implemented it poorly :-)

> -'hot spot compilation' (that was really what we called it): compile heavy-used
> methods from
> bytecode to machine code directly (did we invent the jitter, then?)

No, ParcPlace Smalltalk had it 1984 IIRC. Peter Deutsch's PS (Portable Smalltalk)
engine was really slick, compiled ST-80 bytecodes (very close to Squeak's
bytecodes) to 68K native code. The translator and most platform-independent parts
of the VM were written in 68K macro assembler (we don't need no stinking C). I
think Peter even had some kind of modified browser in which he managed the code,
and an 68K simulator written in Smalltalk in which to try things out. The system
ran on Sun-2 workstations first if my memory serves me correctly.
We (Georg Heeg, Michael Rueger, yours truly and some people whose names escape me
at the moment) ported PS to the PCS Cadmus UNIX workstation and to the Atari Mega
ST, which was a fun project in itself, and really usable for quite some stuff :-)
HPS, the highly portable Smalltalk which was successor to PS and is the
great-grandfather of current VisualWorks, was/is written in C and has a
customizable code generator. HPS probably came out in 1988/89, but this is a very
wild guess.

Cheers,
Hans-Martin






More information about the Squeak-dev mailing list