Hans-Martin wrote:

> The translator and most platform-independent parts of the VM 
> were written in 68K macro assembler (we don't need no stinking C).

	... and Java sucks ;-). 

	Otherwise one might have a peek at:

	
http://www.ibm.com/developerworks/oss/jikesrvm/index.shtml

	Quote:

	"The Jikes™ Research Virtual Machine (Jikes RVM) provides the
academic and research communities with a flexible open testbed to
prototype new virtual machine technologies and experiment with a large
variety of design alternatives. 
The virtual machine infrastructure in the Jikes RVM release was
independently developed over the last four years as part of the Jalapeño
research project at the IBM T.J. Watson Research Center. 

The Jikes RVM runs on AIX™/PowerPC™, Linux©/PowerPC and Linux/IA-32
platforms and includes state-of-the-art virtual machine technologies for
dynamic compilation, adaptive optimization, garbage collection, thread
scheduling and synchronization. A distinguishing characteristic of the
Jikes RVM is that it is implemented in the Java™ programming language
and is self-hosted i.e., its Java code runs on itself without requiring
a second virtual machine. In contrast, almost all other virtual machines
for the Java platform are either written in native code (typically, C or
C++) or written in the Java programming language with a reliance on a
second underlying virtual machine to execute its Java code. A Java
implementation provides ease of portability, and a seamless integration
of virtual machine and application resources such as objects, threads,
and operating-system interfaces. 

University researchers using earlier versions of the Jikes RVM have
found that it provides an ideal vehicle for research on the frontiers of
virtual machine technologies."

	Cheers,

	PhiHo.
 

-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of
Hans-Martin Mosner
Sent: Thursday, April 04, 2002 4:24 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: [Q][VM][ENH][RFH][COMP] Request For Help : CompilerPlugin


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