Hi Matthias,

> Hmm Compiling Smalltalk to C/C++?

> We did this a couple auf years ago (around 1988/89). 

	You mean 1998/99 ? Sorry, how many is one 'auf' :-)

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

	I do not have much experience in this area, but I wonder where
would Squeak be today if Slang was not 'invented'. 

	Maybe, translation to C is only applicable to VM related stuff ?


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

	This is interesting, would you please elaborate. What's the
mechanism to load the methods/object ? Are they in source or binay ? (I
wouldn't push if it's a trade secret :-)

	What I have in mind is a way to tee the output from the Squeak
Compiler so that it can be serialized to disk. Then we will compile the
Compiler itself and all supporting objects, serialize them to disk and
then reconstruct an image which is practically a SqueakCompiler stand
alone (but still needs the VM) Squeak application. What do you think
about this ?


> 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.

	FWIW, MS also released Shared Source CLI (ROTOR) with C# and
(dynamic) Jscript compiler.

	Licensewise, it was posted on Mono list the opinion from one
legal advisor from FSF (?) something to the effect that if you do not
copy verbatim the source from ROTOR, but just reimplement what you
remember and learned from ROTOR source, it's OK.

	I am really counting on MS to make the right moves, that is,
making CLI really language neutral, supporting all languages equally
well. Long ago, they claimed they have a universal VM.

	Of course they were bluffing, but if they are wise, and they can
afford it, they should make it a reality.

	Efforts from MS Research so far gives me hope. Recently, they
even 'spam' the com.lang news groups about their research grants for
work with/improving .Net Framework.

	Now we have Mono, DotGNU and ROTOR, maybe it's about time to
think about Morphic.Monkey ;-)

	Thanks a lot for your informative, helpful posting and sharing
your exeperience.
	
> Cheers, Matthias

	Cheers,

	PhiHo.