Re: Interpreter Optimization

The PARC Place Systems implementation of Smalltalk translates the byte
code form to native machine instruction on a per-method (procedure) basis,
and caches the translated versions. This gives excellent speed/space
tradeoffs, at the expense of considerable added complexity in the
implementation (not the least because in Smalltalk you can get hold of a
frame, ask and modify the pc value, etc., so you have to support
correspondence between byte codes and translated code), and reduced
portability (i.e., more effort to port).


In our own interpreter we force some key interpreter variables into real
registers, and recently replaced the code form:


next_byte_code:
switch (*pc_reg++) {
case push ...
goto next_byte_code;
case pop ...
goto next_byte_code;
...
}


with this (using new features of gcc 2.x):


static void *byte_code_locs[256] = { &&push, &&pop, ... };


push ...
goto byte_code_locs[*pc_reg++];
pop ...
goto byte_code_locs[*pc_reg++];


This latter optimization was worth about 15% on a MIPS. Threaded code
might do a little better, but gets into translation (since Smalltalk
specifies the byte code representation, which is visible to Smalltalk
code). Getting the right variables into registers was worth about the same
amount, as I recall. There are other tricks used (mostly related to
caching) that help with the dynamicity in Smalltalk.
--


J. Eliot B. Moss, Assistant Professor
Department of Computer Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
--

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