|Mixing virtual and real machine code in an interpreter email@example.com (1994-03-16)|
|Re: Mixing virtual and real machine code in an interpreter firstname.lastname@example.org (1994-03-21)|
|Re: Mixing virtual and real machine code in an interpreter email@example.com (1994-03-22)|
|Re: Mixing virtual and real machine code in an interpreter firstname.lastname@example.org (1994-03-22)|
|Re: Mixing virtual and real machine code in an interpreter email@example.com (Steven D. Majewski) (1994-03-23)|
|Re: Mixing virtual and real machine code in an interpreter firstname.lastname@example.org (1994-03-30)|
|From:||"Steven D. Majewski" <email@example.com>|
|Organization:||University of Virginia|
|Date:||Wed, 23 Mar 1994 02:12:00 GMT|
Graham Matthews <firstname.lastname@example.org> wrote:
>I am interested in the problem of mixing sections of real and virtual machine
>code. I have an interpreter for a language L that compiles L into a virtual
>machine code and executes this. For certain critical sections, I would like to
>compile into native assembler. I envisage having some sort of virtual machine
>instruction that jumps to a section of real machine instructions, and
>similarly jump back ...
FORTH words are entries in a dictionary, with a Code Field Address (CFA)
and a Parameter Field Address (PFA)
The CFA is the address of the code that interprets the Parameter Field.
When the entry is a Forth defined word, the Parameter Field contains
threaded code ( Tokens or addresses ) and the CFA points to a routine
typically called DOCOL ( for "do colon" - a Forth definition begins with a
":" ) which is the threaded code interpreter.
Forth systems usually have an assembler to code new primitives - which are
coded the same as the builtin predefined words: the CFA points to the PFA
- the parameters field contains machine code - and it jumps to that code.
A Forth code optimizer could be constructed which creates a new version of
a word by recursively inlineing the threaded code until it has been
expanded to primitives ( assuming PIC primitives )
To reiterate some old threads from comp.arch:
Interpreter virtual machines are typically stack-machines. Running a
virtual stack machine on a register-rich RISC processor loses the
capability to use all those RISC registers. Also, the inner interpreter in
Forth and other interpreted languages are usually tight loops around
indirect jumps - just the type of code that typically doesn't pipeline
well. Interpreted code usually has a higher RELATIVE disadvantage running
on a RISC processer. ( This is inferring a pattern from numerous published
benchmarks. ) So *avoiding* interpreted code, and inlineing on a RISC
should be that much *more* of a win.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
Return to the
Search the comp.compilers archives again.