Douglas Brebner wrote:


> That's the sort of thing I was hoping could be done.
> <pipedream>
> Could it be made to handle other languages too? Maybe for the C interpreter
> mentioned on http://mathmorphs.swiki.net/50?
> </pipedream>
Well I guess that one could make a front end that would  do that, but I
remember with horror the amount of work it took to write the C
headerfile parser for the VW FFI system back in 92/3/4. It might be a
rather large amount of work for dubious value - after all there are C
compilers out there that already do that work. There are even (if legend
can be believed) people _that like writing C compilers_!


> Could the translator produce code in the manner that Jitter expects? That
> way, the translation part of Jitter can be removed leaving the native code
> execution engine. Or would that be excessively complex?
To a first approximation, if you removed the translation part of the
jitter you would have almost nothing left. There is an improved stack
design that the J3 system provides and takes advantage of, but I think
it is fair to say it could pretty much be used independently.

I suspect the thing to do would be to have an instvar in each compiled
method that can have nil or a wordarray of translated machine code. If
it's nil, the interpreter runs the bytecodes and adds the method to a
list for potential translation. If it's a wordarray, run it, assuming it
is correct code. I wonder if there is a nice way to fold primitives into this?
>

> And of course with VMMaker and the translator, building new VMs and plugins
> could potentially be done with a few mouse clicks :)
Well, that's pretty much true now :-)



> It would be nice if they could optionally hold on to code across snapshots.
> Persistant native code could be useful for SqueakNOS  device drivers and
> maybe the translator and some essential bits to allow for full native
> execution.
Oh, surely. Some startup code that knows it is returning from a snapshot
rathe rthan starting fresh should handle that.