Re: Public domain Pcode spec/interpreter (Mark Lentczner)
Tue, 20 Sep 1994 15:57:43 GMT

          From comp.compilers

Related articles
Public domain Pcode spec/interpreter ? (1994-09-11)
Public domain Pcode spec/interpreter (Paul Robinson) (1994-09-17)
Re: Public domain Pcode spec/interpreter (1994-09-17)
Re: Public domain Pcode spec/interpreter (1994-09-18)
Re: Public domain Pcode spec/interpreter (1994-09-20)
Re: Public domain Pcode spec/interpreter bfaust@saratoga.physik.Uni-Osnabrueck.DE (1994-09-21)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Mark Lentczner)
Keywords: code, smalltalk
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: 94-09-033 94-09-096
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
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

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

- Mark Lentczner
    Glyphic Technology

Post a followup to this message

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