"PhiHo Hoang" <phiho.hoang at rogers.com> is claimed by the authorities to have
written:

> 	The twisted trick here is that, the compiler in bytecode is
> going to generate C/C++ (on top of generatimg bytecode as usual), but
> the compiler in C/C++ is going to generate bytecode ;-)
So you want to make vm plugin that is a replacement for the compiler in the
image? I'm not sure that is a practical idea. Digitalk used to do it (well,
nearly), but it has the disadvantage that fixing the compiler is harder.
Besides, the performance of the compiler is not exactly critical in many
scenarios.

> 	However, it can be considered a bonus if we can compile
> standalone Squeak application into native code (preJITted ?).
I've written several times about a possible jitter-in-squeak, but I wouldn't
consider that as a vm plugin particularly. I suppose it might be possible, but
remember that turning arbitrary Smalltalk into C is unlikely to provide a
serious speedup and will certainly provide some exciting adventures in
complexity. Apart from anything else C is a dismal language for expressing a
lot of things useful to a vm. Well, actually, it's pretty dismal full stop.
 
> 
> 	Wouldn't it be beautiful if Etoy or and app that makes heavy use
> of Morphic and Ned's connector animation now run at the speed of '450'
> ;-) times the speed of running in bytecode within the image !
> 
> 	Can you say 'games' ;-)
Can you say "I really must stop taking these wierd drugs" ? :-)
> 
> 	Actually, the main thing I am interested in the backend that
> generates C/C+ is to generate the compiler itself into C/C++ so that it
> can be built as a plugin, to become another thingy in SqMOM.
Much simpler to have it as a demand loaded image module I suspect and more
flexible to boot. 
> 
> 	All other plugins are now currently handled by Slang, a subset
> (and C-ized ;-) of Squeak.
> 
> 	A backend to Squeak compiler that generate C/C++ would make
> Slang obsolete. I hope you like this :-)
I would love to see Slang obsoleted by something better; I've spent a large
amount of time wading in Slang and know far more about its failings than I 'd
like. BUT. The problem Slang tackles is not that of converting normal Smalltalk
into C, it is meant to produce the C code for the vm. By working in a very
restricted idiom you can practicably convert message sends into C direct
function calls, something that you just can't do for an arbitrary case.

Consider this; the Squeak compiler is a quite large complex bunch of classes
that does it's job pretty well. To convert it to C you would have to, amongst
other things, make said C code use message sending, object allocation, garbage
collection etc to provide the same functionality. The options for providing
much of a speedup are pretty slim, sure a few loop constructs might be a bit
faster but you'd still have to send messages inside the loop or the semantics
would be broken. To get around this, you'd have to write a quite different
compiler in a more traditional manner, and then have a translator that
understood the restrictions involved and generated the appropriate C code. Hey,
thats....Slang! Or write it in C directly - baaaaaarf.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
The generation of random numbers is too important to be left to chance.