Internal code representation.

markg@athens.emi.net (Mark Grosberg)
Sat, 14 Oct 1995 06:27:42 GMT

          From comp.compilers

Related articles
Internal code representation. markg@athens.emi.net (1995-10-14)
Re: Internal code representation. sgt20@cam.ac.uk (1995-10-23)
Re: Internal code representation. ganswijk@xs4all.nl (Jaap van Ganswijk) (1995-10-23)
| List of all articles for this month |

Newsgroups: comp.compilers,comp.programming,comp.lang.misc
From: markg@athens.emi.net (Mark Grosberg)
Keywords: interpreter, question
Organization: EmiNet Domain Internet Services (407)731-0222
Date: Sat, 14 Oct 1995 06:27:42 GMT

Hello there.


I am currently coding yet another (experimental) language interpreter.
In all of my previous intepreters I used a RPN-based stack representation
once code was absorbed and a stack to do evaluation.


Lately, I have not been happy with that solution because:


    (1) I have to allocate a chunk of memory for a stack.
    (2) Can't modify the code at runtime as easily because the
            internal representation doesn't look much like the actual
            code
    (3) Haven't figured out a good way for lazy evaluation yet.


One method of internal code representation that I did think of was
(similar to Lisp) each function call consisted of an array of the
parameters to that function, and at execute time, that pointer was passed
to the evaluator.


The problem with this is if you have a function, f(a)=(a+a) and you call
it with f(sin(1))


sin(1) gets evaluated twice. While sometimes this is desierable
behaviour, sometimes it isn't.


I am trying to find a compromise between these two cases as in this new
language I am exploring continuations (and some forms stuff) and would
like the ability to pass code around and have it executed as many times
as necessary (think of a "for-each" function here).


One way of doing this is dynamic binding, but I don't have much
experience with this.


Any help or hints towards a good internal code representation would be
appriciated, preferrably one that is both efficient and supports lazy and
iterated parameter evaluation.


Thanks guys,
Mark G.
--


Post a followup to this message

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