Re: Mixing virtual and real machine code in an interpreter

graham@pact.srf.ac.uk (Graham Matthews) writes:


>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


One approach was implemented in Dynascope which allowed mixing of C
functions, compiled either to real or virtual code. At runtime, functions
can be dynamically loaded or linked, regardless of their code type.
Functions with real and virtual code could be arbitrarily mixed.


A call from virtual to real code is easy, you just need a virtual
instruction to call real code.


A call from real code to virtual code is a little trickier and usually
requires indirection. It was simplified in Dynascope because of support
for dynamic linking. When a call from real code to virtual code is
detected during linking, a stub is generated which: (a) copies parameters
to the interpreter stack, (b) saves the interpreter state (for recursive
calls to the interpreter), (c) sets up the new interpreter state (this is
the main part different for each virtual function), (d) calls the
interpreter, (e) upon return, removes parameters from the stack, (f)
restores the interpreter state, (g) returns the result. This stub is then
called from real code.


>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.


As pointed out by others, savings depend on the application. Nevertheless,
here are some numbers. In Dynascope, virtual code was from 50 to 100 times
slower than real code, depending on the frequency of library and system
calls. The overhead was lowered to around 15% by replacing all functions,
except the top level function, with their equivalents in real code. This
represents the lower bound on the overhead in Dynascope.


A reference paper for Dynascope is: R. Sosi\v{c}, Dynascope: A Tool for
Program Directing, Proceedings of {SIGPLAN}'92 Conference on Programming
Language Design and Implementation, 1992, pp. 12-21.


Some more details on the implementation of Dynascope could be found in my
thesis: The Many Faces of Introspection, Department of Computer Science,
University of Utah, 1992, available by ftp from:
ftp.cit.gu.edu.au:pub/R.Sosic/rok-thesis.ps.Z


Cheers,
Rok


--
Rok Sosic (sosic@cit.gu.edu.au)
School of Computing & Information Technology
Griffith University, Nathan, QLD 4111, AUSTRALIA
phone: +61 7 875 5026; fax: + 61 7 875 5051
[It occurs to me that this sort of intermixture of compiled and interpreted
code was supported by the IBM PL/I X (optimizing, real code), and CK
(checkout, interpreted) compilers using interpreter stubs. No dynamic linking,
you had to compile and link everything together and, as I recall, tell CK
which stubs to generate. -John]
--

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