Re: Intermediate language

Jim Prince <tools2@gate.net> writes
>I tried to start a discussion on intermediate languages and was
>unsuccessful. Thank you to the people that replied directly to me.
>What I would like is a discussion on the what, where, whys of
>designing an intermediate language. I have read the red dragon book
>and others and have been confused. I would like to abstract the
>problem, but do not have enough experience.


In principle, you use an intermediate language (though I prefer the
term intermediate representation), to make 'post-parse' processing
easier or more convenient.


Possible forms of representaion are myriad, including trees, DAGs,
triplets, linear codes, tables, reverse polish and others that I have
forgotten or don't know about. There are many variant possibilities -
eg. if you use a tree to represent statements and expressions you must
still choose how to represent data declarations, scopes etc., by
tables, digraphs or something else.


A single compiler may use a number of different representations, at
different (or even at the same time(s).


Even a single-pass compiler must represent the program in some
internal form as it processes it (though probably 'on-the-fly' and
usually only a fragment at a time).


My personal choice, for a conventional multi-pass compiler for a
language like Ada or C, is to generate an Abstract Syntax Tree at
parse time with a Name Table and to decorate this tree with attributes
as semantic information is generated (whether these attributes are
pointers to tables or form parts of digraphs is, again, a matter of
convenience).


Whether it is necessary to contruct control flow-graph for
optimisation purposes depends, again on how you do it. Again,
personally, I prefer to perform flow analysis using a High Level
technique directly on the tree - others do it differently. If you do
need a flow graph you can generate a digraph or you could use an
adjacency bit-matrix.


Depending on your target (and to some extent the language) you may
generate assembler (or relocatable binary) direct or you may need an
additional intermediate linear code, which may be an idealisation of
the real target but perhaps with in artbitrary number of registers or
may be a more abstract form (eg. if you have several different
targets).


As you can see, there is room for plenty of variety.


Which to choose - there is no *general* right or wrong answer,
compilers are engineering and engineering is the art of making the
right 'trade- offs', between size and speed, implementation cost and
efficiency, compilation time and execution time etc., etc.......


I hope that this was the kind of thing you were looking for and that it
starts a nice frindly but heated debate.

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