|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)|
|I-cache consistancy (WAS: Mixing virtual and real machine ...) firstname.lastname@example.org (1994-03-24)|
|Re: Mixing virtual and real machine code in an interpreter email@example.com (1994-03-30)|
|From:||firstname.lastname@example.org (Graham Matthews)|
|Keywords:||interpreter, question, comment|
|Organization:||University of Bristol, England|
|Date:||Wed, 16 Mar 1994 07:57:39 GMT|
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
a jump back ...
I was wondering then (and these may be dumb questions!) :-
a) how difficult it is to mix and match such sections of real and virtual
machine code? For example how do you access the interpreter's state from
inside the real machine code section? Also on machines with different data and
instruction space, how can you invoke the real machine instructions, which
will be in data space? Compiled Lisp systems seem to allow you to do this,
so it must be doable - or do they not do this and instead have a virtual
machine code that simply threads calls to compiled C (for example)?
b) if anyone had done this, and had some performance figures (or guestimates)
for how much an interpreter implementing a language L saves in execution
speed by actually compiling sections of L code into native assembler,
rather than say into a virtual machine code.
[Mixing real and virtual code is a standard technique. Typically you
call functions indirectly and jump either to the actual code or to an
interpreter entry point. Real code rarely looks inside the interpreter,
but rather shares application data. Re instruction and data spaces, you
need some operating system hack to let you write into instruction segments.
Return to the
Search the comp.compilers archives again.