Interval translator (was: Re: Sharp Zaurus SL-5000D Linux (Squeak?) PDA)
Douglas Brebner
douglas+list at fang.demon.co.uk
Sun Dec 2 22:00:28 UTC 2001
On Sunday 02 December 2001 19:22, Tim Rowledge wrote:
> 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.
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>
> 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.
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?
I'm envisioning a system where the image starts up with the bytecode
interpreter, the translator and other essential bits are translated and then
control passes from the interpreter to the Jitter engine and the rest of the
image is translated on-the-fly.
> 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.
And of course with VMMaker and the translator, building new VMs and plugins
could potentially be done with a few mouse clicks :)
> > > 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.
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.
--
Douglas
More information about the Squeak-dev
mailing list
|