Re: Public domain Pcode spec/interpreter

To continue on the native/pcode aspect of this thread:


A number of years ago I worked on the Apple Computer version of
Smalltalk-80. This was a standard bytecode (= pcode) style
implementation. Smalltalk mixes native code by having a predefined set of
primitives. When a method (= function) is entered it is checked to see if
it contains bytecodes or a primitive number. In the latter case the
primitive code is invoked. I created an experimental version of the system
that allowed the programmer to write its own methods in 68000 assembly.
In this system methods were checked for a flag that indicated if they were
bytecodes or real machine language. In the later case the interpreter
simply jumped to the code.


This system got around the calling conventions problem that David Keppel
had to face: The conventions were just the state of the pcode interpreter
on entry to a method. It also didn't allow re-entry into pcode from
machine language.


For the last two and a half years I have been working on a language that
DOES allow machine code to bytecode calling and uses host standard C
calling conventions. We have found that the cost of the "brain-swap" is
large enough that it has to be weighed into the decision to locate a piece
of code in C or in bytecodes. Occasionally we end up writing two versions
of a routine, one to call from C and one from bytecodes. Note that this
situation is very similar to the 680x0 emulation on the PowerPC version of
Macintosh.


Our overhead in "brain-swapping" is high for a number of reasons, many of
which are specific to our language. Some are likely to be universal
problems:


1) We support closures and error catch/throw accross the
C/bytecode boundry in either direction. This involves transferring
more information with each call accross the C/bytecode boundry
in either direction.


2) The bytecode interpreter is very optimized and makes
extensive use of registers. Getting set up to start
interpreting bytecodes takes a fair amount of work. Obviously
this only seriously affects the C->bytecode calls.


3) The bytecode system is fully re-entrant and multitasking.
When we call out from bytecode to C, we can't be assured the
next call from C to bytecode will be the same process. Hence we
have more state to save and restore on entry and exit to the
bytecode system.


- Mark Lentczner
    Glyphic Technology
    markl@netcom.com
--

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