Joshua 'Schwa' Gargus wrote:
> 
> On Sun, Dec 02, 2001 at 02:28:59PM +0000, Douglas Brebner wrote:
> > > Of course there is the ol'Interval translator.....
> >
> > Has anyone been working on this? It seems to me this could be a more powerful
> > tool than Jitter.
> 
> Except that you have to write in Slang.  It is certainly a nice complement to
> Jitter, but not a replacement.
This is true right now - it takes a slightly evolved form of Slang as
its input stream. However, I doubt it would be beyond some of you CS
jocks out there to extend it to take normal Smalltalk. After all, Slang
is merely a subset. Since it already knows how to output C source, ARM
assembler source and ARM object code, I'm guessing it would be a
reasonable starting point for an in-image jitter system.

This isn't a new idea, by the way, Ian P wrote a thesis on something
like this and I think his paper referenced still earlier similar
suggestions. Rather than having a complex system hidden in the VM (as
with the current jitter, the VW dynamic translator etc) to convert
bytecodes to machine code, with all the attendant problems of it being
hidden, you can have the convertor in the image and potentially have a
very sophisticated compiler available. Even sending out across the net
for a translator service would be possible! Improvements in performance
due to better optimisation would be available via normal updating rather
than waiting for a new vm.

Of course, you have to have something to run bytecodes until the
translator has produced machine code; a normal interpreter is perfectly
adequate and in fact a really small simple one would do. It could be a
plugin that gets dropped automatically when everything is translated.

A big advantage of a sytem like this is the cofiguration flexibilty that
becomes possible. You could use an image _without_ the translator on
small machines or for a script running system. On a 'normal' machine you
load the module with the basic translator and on large servers you might
use a more exacting translator that works really hard and assumes a
static codebase with no reflection etc etc.


> > Related to this, would the new compiled method format be able to handle
> > (possibly multiple) native codes in addition to byte codes? This could be
> > handy for the SqueakNOS people too.
The NCM changes remove the ugly magic from the copiled method format and
make it a regular object. This means that adding extra instance
variables becomes easy and an array of translated machine code would
easy. More likely useful would be a weak pointer that goes away in a
snapshot. Other people have expressed a wish to add ivars for security,
database and sourcecode management purposes.

tim