|ultra fast but too complex interpreter. firstname.lastname@example.org (1993-03-17)|
|Re: Re: ultra fast but too complex interpreter email@example.com (Anton Ertl) (1993-03-18)|
|ultra fast but too complex interpreter. firstname.lastname@example.org (1993-03-19)|
|Re: ultra fast but too complex interpreter. email@example.com (1993-03-19)|
|ultra fast but too complex ... summary firstname.lastname@example.org (1993-03-22)|
|Re: ultra fast but too complex ... summary email@example.com.OZ.AU (1993-03-23)|
|ultra fast but too complex ... appendum firstname.lastname@example.org (1993-03-24)|
|From:||email@example.com (Frans van Hoesel)|
|Organization:||University of Groningen, the Netherlands|
|Date:||Wed, 17 Mar 1993 15:27:05 GMT|
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
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 van hoesel firstname.lastname@example.org === ----
Return to the
Search the comp.compilers archives again.