Re: Q: Intermediate code for interpreting & compiling?

>>>
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]
--

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