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

Matthias.Klein at tlc.de Matthias.Klein at tlc.de
Thu Apr 4 08:02:19 UTC 2002



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 :-))

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)
-'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?)

Btw: has someonle looked at the "mono"-project (.NET on linux). They have a
jitter for the .NET-bytecodes based on a simplified version of BURS. Something
like that should be quite portable to other CPU architectures.


Cheers, Matthias





More information about the Squeak-dev mailing list