Related articles |
---|
ultra fast but too complex interpreter. hoesel@igc.ethz.ch (1993-03-17) |
ultra fast but too complex interpreter. hosking@cs.umass.edu (1993-03-19) |
Re: ultra fast but too complex interpreter. drw@euler.mit.edu (1993-03-19) |
Newsgroups: | comp.compilers |
From: | drw@euler.mit.edu (Dale R. Worley) |
Keywords: | interpreter |
Organization: | MIT Dept. of Tetrapilotomy, Cambridge, MA, USA |
References: | 93-03-060 |
Date: | Fri, 19 Mar 1993 20:18:56 GMT |
hoesel@igc.ethz.ch (Frans van Hoesel) writes:
this approach has a lot(!!!!!) of instructions with functions like
add_i0_i1_i4 (add integer register i1 to integer register i4 and store the
result in i0) and create a beast of of data structure in which the code
generator can find which functions are implemented and what their address
is. The intrepeted code is then a list of function addresses to execute.
3) a third method is to have one add function give it a unique small
number, and use bit fiddling to find out which registers to add (by means
of a very big switch statement, or something like that)
My approach would be to have a small number of opcodes (which would then
fit in 1 byte), some of which would be followed by one or more 1 byte
arguments giving register numbers. Thus, add_i0_i1_i4 would be encoded as
the sequence of 4 bytes:
14 (code for ADD)
0 (for i0)
1 (for i1)
4 (for i4)
Depending on the circumstances, there are changes that could make this
better. For instance, if you have 64 registers or less, you can store the
register numbers multipled by 4 (0, 4, and 16 in the above example), so
the interpreter can use the argument byte directly as an offset from the
base of the register set.
Dale
Dale Worley Dept. of Math., MIT drw@math.mit.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.