Re: Decompilable interpreter/compiler hybrid

vbdis@aol.com (VBDis)
13 Jul 2003 23:49:50 -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: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 13 Jul 2003 23:49:50 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 03-07-022
Keywords: interpreter, forth
Posted-Date: 13 Jul 2003 23:49:49 EDT

samir.ribic@alemsistem.com.ba (Samir Ribic) schreibt:


>AFAIK, the most similar concept has language Forth, however it still
>needs an interpreter.


The Forth "interpreter", if I understand you right, does nothing but
read the next Word and invoke its implementation. Much more code and
data is required for the conversion between text and the internal
representation, in both directions, in any solution. The
implementation of only an disassembler for machine code requires much
code and data, with no upper limits for the implementation of an
decompiler.


An implementation of your intended language depends on the actual
machine instruction set, and on the availability of ROM or other non
volatile memory, which can be mapped or loaded into the address
space. IMO the editor, i.e. the compiler and decompiler, will consume
most of the available address space, so that without overlays not much
space will be left for the programs. You also should consider that the
symbol table, for the names of procedures and variables, may consume
more space than the compiled code itself. You'll also need some
sophisticated memory management, which allows to move the code in
memory during editing, and to fix up all moved code references before
the execution of the modified code. Forward references also should be
considered, otherwise all functions must be entered before they can be
referenced in other functions.




In Forth the difference between compilation and interpretation is
determined by the STATE variable. The Forth input loop reads the next
textual token, and separates literals (numbers) from identifiers. In
the interpreting state all numbers are pushed onto the stack, and
identifiers are searched in the dictionary and then their
implementation is invoked. In the compiling state numbers are compiled
into appropriate tokens, and identifiers are treated in one of two
ways, depending on their IMMEDIATE property; immediate words are
always invoked, whereas non-immediate words are stored as code.


IMO this is a very elegant and fly-weight implementation of an user
interface, whose capabilities can be extended to any complexity by
adding new immediate words, as required by the actual goal. In your
case the goal will be a language with a small compiler and
decompiler. This may be achievable in Forth, provided that the
language is based on RPN. Otherwise just the conversion of expressions
between RPN (as used in the executable code) and any other
representation may require much code.


DoDi


Post a followup to this message

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