ultra fast but too complex interpreter.

hoesel@igc.ethz.ch (Frans van Hoesel)
Wed, 17 Mar 1993 15:27:05 GMT

          From comp.compilers

Related articles
ultra fast but too complex interpreter. hoesel@igc.ethz.ch (1993-03-17)
Re: Re: ultra fast but too complex interpreter anton@mips.complang.tuwien.ac.at (Anton Ertl) (1993-03-18)
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)
ultra fast but too complex ... summary hoesel@igc.ethz.ch (1993-03-22)
Re: ultra fast but too complex ... summary fjh@mundil.cs.mu.OZ.AU (1993-03-23)
ultra fast but too complex ... appendum hoesel@igc.ethz.ch (1993-03-24)
| List of all articles for this month |

Newsgroups: comp.compilers
From: hoesel@igc.ethz.ch (Frans van Hoesel)
Keywords: interpreter, question
Organization: University of Groningen, the Netherlands
Date: Wed, 17 Mar 1993 15:27:05 GMT

Hi everyone,


My interpreter of a language of my own (yes again a data processing
language) is at the stage where I need to write the low level stuff. I
cannot decide between three options (there may be more) 1) ultra fast but
complex


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.
This machine pretends to have real registers. On my r3000 indigo, these
pseudo registers can be made fast by accessing them from the global data
pointer. This approach is what I'm trying at this very moment.


I wrote already a generator for all those add_ instructions and some more
and have already over 1500 functions!!!. This is getting out of hand. But
then again I think well, who cares, let the computer deal with it (and
hopefully the linker will keep up with this amount of functions)


2) a second approach is a simple stack machine


This would be easy to make, but most likely not very fast.


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)


The questions is.. how did you guys attack this problem and why did you
choose the way you have done it?


please send me your thoughts , so my reasoning gets on track again (I lost
already two weeks of work, not being able to pick the right method)


- frans
--
frans van hoesel hoesel@igc.ethz.ch === ----
--


Post a followup to this message

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