Re: Q: Intermediate code for interpreting & compiling?

danhicks@aol.com (DanHicks)
Wed, 22 Feb 1995 02:55:16 GMT

          From comp.compilers

Related articles
Q: Intermediate code for interpreting & compiling? davis@wln.com (1995-02-10)
Re: Q: Intermediate code for interpreting & compiling? torbenm@diku.dk (1995-02-14)
Re: Q: Intermediate code for interpreting & compiling? cef@geodesic.com (Charles Fiterman) (1995-02-14)
Re: Q: Intermediate code for interpreting & compiling? danhicks@aol.com (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? zmola@cicero.spc.uchicago.edu (1995-02-24)
Re: Q: Intermediate code for interpreting & compiling? davidm@Rational.COM (1995-02-28)
Re: Q: Intermediate code for interpreting & compiling? anton@mips.complang.tuwien.ac.at (1995-03-01)
| List of all articles for this month |

Newsgroups: comp.compilers
From: danhicks@aol.com (DanHicks)
Keywords: interpreter, code, comment
Organization: America Online, Inc. (1-800-827-6364)
References: 95-02-103
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
parameter.


Dan Hicks
[Hey, lots of languages have thunks. But now we call them function pointers.
-John]
--


Post a followup to this message

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