|Public domain Pcode spec/interpreter ? firstname.lastname@example.org (1994-09-11)|
|Public domain Pcode spec/interpreter PAUL@tdr.com (Paul Robinson) (1994-09-17)|
|Re: Public domain Pcode spec/interpreter email@example.com (1994-09-17)|
|Re: Public domain Pcode spec/interpreter firstname.lastname@example.org (1994-09-18)|
|Re: Public domain Pcode spec/interpreter email@example.com (1994-09-20)|
|Re: Public domain Pcode spec/interpreter firstname.lastname@example.org.Uni-Osnabrueck.DE (1994-09-21)|
|From:||email@example.com (Mark Lentczner)|
|Organization:||NETCOM On-line Communication Services (408 261-4700 guest)|
|Date:||Tue, 20 Sep 1994 15:57:43 GMT|
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
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
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
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
- Mark Lentczner
Return to the
Search the comp.compilers archives again.