|Q: Intermediate code for interpreting & compiling? email@example.com (1995-02-10)|
|Re: Q: Intermediate code for interpreting & compiling? firstname.lastname@example.org (1995-02-14)|
|Re: Q: Intermediate code for interpreting & compiling? email@example.com (Charles Fiterman) (1995-02-14)|
|Re: Q: Intermediate code for interpreting & compiling? firstname.lastname@example.org (1995-02-22)|
|Re: Q: Intermediate code for interpreting & compiling? Dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-02-24)|
|Re: Q: Intermediate code for interpreting & compiling? email@example.com (1995-02-24)|
|Re: Q: Intermediate code for interpreting & compiling? davidm@Rational.COM (1995-02-28)|
|Re: Q: Intermediate code for interpreting & compiling? firstname.lastname@example.org (1995-03-01)|
|Keywords:||interpreter, code, comment|
|Organization:||America Online, Inc. (1-800-827-6364)|
|Date:||Wed, 22 Feb 1995 02:55:16 GMT|
I am looking for some type of solution to a problem that I think arises
enough. I am programming a language that will act much like smalltalk,
namely, that it will be incrementally compiled into some form of
intermediate code that will later be compiled OR interpreted. I would like
it to be as generic (i.e. platform independant) as possible as I only
really want to write it once and recompile on multiple machines with as
little tweaking as possible... C is not a valid intermediate because then
I would be implementing 2 languages at once and I'm not up to that yet...
(Student, ya know...) that, and I think it would be easier to bring it to
a lower level than that...
The classical response (as has already been mentioned) is a stack
notation. However, I think there's another notation that deserves
consideration: A LISP-like notation. I'm not necessarily suggesting
either the textual parenthesized form, or the internal linked-list form,
but rather a length-prefix form. Each list can be prefixed by a length
word, with one bit devoted to distinguishing between lists and atoms.
This format is nearly as efficient to parse as machine-readable stack
notation, but it has several advantages.
Two of those advantages: 1) "Structured" control structures can be easily
represented, whereas stack notations need to either use branch/label
schemes or introduce additional structuring concepts. (A disadvantage,
though, is that non-structured code is quite difficult to represent.) 2)
It is easy to implement "thunks". Now few languages have "thunks" any
more, but thunks are still a useful concept internal to a compiler, and
with the LISP-like notation it is easy to pass a piece of pseudo-code as a
[Hey, lots of languages have thunks. But now we call them function pointers.
Return to the
Search the comp.compilers archives again.