Re: Decompilable interpreter/compiler hybrid

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

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