Re: Decompilable interpreter/compiler hybrid

"Alex McDonald" <alex_mcd@btopenworld.com>
4 Jul 2003 00:07:34 -0400

          From comp.compilers

Related articles
Decompilable interpreter/compiler hybrid samir.ribic@alemsistem.com.ba (2003-07-02)
Re: Decompilable interpreter/compiler hybrid tdk@thelbane.com (Timothy Knox) (2003-07-04)
Re: Decompilable interpreter/compiler hybrid alex_mcd@btopenworld.com (Alex McDonald) (2003-07-04)
Re: Decompilable interpreter/compiler hybrid Martin.Ward@durham.ac.uk (Martin Ward) (2003-07-04)
Re: Decompilable interpreter/compiler hybrid vbdis@aol.com (2003-07-13)
| List of all articles for this month |
From: "Alex McDonald" <alex_mcd@btopenworld.com>
Newsgroups: comp.compilers
Date: 4 Jul 2003 00:07:34 -0400
Organization: BT Openworld
References: 03-07-022
Keywords: design
Posted-Date: 04 Jul 2003 00:07:34 EDT

"Samir Ribic" <samir.ribic@alemsistem.com.ba> wrote in message


===snipped
> The language is aimed for diskless computers with very low RAM (8 bit
> computers or pocket devices) where keeping source and object code in
> memory is too limiting, while interpreters are too slow.
>
> Does such kind of decompilable interpreter/compiler hybrid exist?
> AFAIK, the most similar concept has language Forth, however it still
> needs an interpreter.
>


You really should reinvestigate Forth, especially cross-compiled Forths.


Forth has two interpreters, an outer interpreter and an inner interpreter.
The outer interprets the source code and builds the executable (in some
forths, a series of execution tokens; in others, machine code subroutines)
that the inner interpreter executes. The inner interpreter is, in closest
analogy, a VM. Cross-compiled Forths have the outer interpreter/compiler on
the source machine; the target is just the code you wish to execute, along
with the inner-interpreter, which has an _extremely_ small footprint. Most
inner interpreters are measured in 10s to 100s of bytes.


For a commercial solution see
http://www.forth.com/Content/Products/SwiftX/SwiftX.htm, a product from
Forth inc that targets a wide range of devices; they claim to be able to
retarget to most devices in 2 to 3 weeks. Applications developed this way
are perfectly ROMable. Devices currently supported include 68Ks, ColdFire,
68HC11/12, 8051, others...


Or, if you're wanting to try your hand at developing your own based on other
work, look at pygmyForth, developed by Frank Sergeant. To quote: "A
3-instruction Forth makes Forth affordable for target systems with very
limited memory. It can be
brought up quickly on strange new hardware. It only takes 66 bytes for the
Motorola MC68HC11. Full source is provided." Worth a look at
http://www.eskimo.com/~pygmy/forth.html. And Brad Rodriguez' site
http://www.zetetics.com/bj/papers/ describes the techniques used in Forth
systems, and provides a tutorial on designing a Forth for Z80/6501/6809
chips.


Oddly, an execution token Forth can be much smaller than machine code. This
makes it ideal for small imbedded devices. It also has the advantage that
the token is translatable back (in most cases) to the original source code.
Speed need not be compromised either; optimising Forths can produce code
that is as fast as C.


--
Regards
Alex McDonald


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.