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