Tim Rowledge wrote:

>> 	I think the best solution is a backend to the Squeak compiler to

>> generate C/C++.

> You're going to have to help me a bit here; why? So you change the
compiler to produce C 
> instead of bytecodes - ok I could just about imagine that. Ugly, but I
wouldn't claim that 
> reading bytecodes is much better. 

	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 ;-) Otherwise I will
be handing out the pink slip to SqM pretty soon when all compilers just
generate C/C++ , no more fun ;-). 

	However, it can be considered a bonus if we can compile
standalone Squeak application into native code (preJITted ?). 

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

	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. 

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

> Now what? You spawn off a process (OS proces, heavy weight, takes ages
to get moving, not 
> possible on all machines) to run gcc on your generated code. It will
need a bunch of 
> background info to make sense of your little converted method;
globals, instvars, class vars, 
> etc. Obviously it can be done - Claus did it for ST/X some time ago.
I'm not sure it has a 
> particularly obvious payoff though. 
> Remember that you're not going to get any enormous speedup for general
Smalltalk code; 
> messages still have to be sent, bounds have to be checked etc.

	No, it's too complicated. I'd rather have something simple and
powerful ;-)

	Isn't it wonderful if we can use our beautiful and lovely Squeak
to write plugins. (instead of that half cooked ugly C-ized Slang ;-) (No
offense here ;-)

>> 	My gut feeling is that, a CompilerPlugin would help quite a bit
to 
>> attain the goal of a really modular Squeak. I think the proof is in 
>> 'gst', SmallScript (?).

> An execution engine that is modularized is certainly a useful
possibility as I've said many 
> times before. I do have trouble seeing C generation (beyond what we
have for vm code) as being > much of a benefit though. Personally I'd
rather not even have C involved there either :-)

	Just imagine, with a CompilerPlugin, ModManPlugin will just grab
FreeCell.st, throws it at CompilerPlugin which will compile it (into
bytecode) then throw it at ObjectMemoryPlugin which tries to stuff it
into ObjectMemory and 'discovers' that something is missing, it will
bark at ModManPlugin, somehow ModManPlugin will try to resolve what is
missing and try to pull it from the net.

	And so on, and so forth. And The Network is The Mouse, the whole
of it now.

	Did I miss something ? 
	Am I ahead of myself ? 
	How badly did I show my stupidity ;-)


	Cheers,

	PhiHo.