|INTERMEDIATE CODE DESIGN email@example.com (1995-06-24)|
|Intermediate code design firstname.lastname@example.org (David Stone 5887) (1998-01-05)|
|Re: Intermediate code design email@example.com (1998-01-06)|
|Re: Intermediate code design firstname.lastname@example.org (David Chase) (1998-01-06)|
|Re: Intermediate code design email@example.com (Charles Fiterman) (1998-01-08)|
|Re: Intermediate code design firstname.lastname@example.org (Christian von Roques) (1998-01-08)|
|From:||David Stone 5887 <email@example.com>|
|Date:||5 Jan 1998 13:21:08 -0500|
I have two questions about intermediate code design.
I assume a conventional 3-operand style of intermediate code:
destination and two source operands.
(1) Updating operations.
Suppose the source language supports updating operations, for example
x += y in C.
Should this become
x = x + y
in intermediate code (using temporaries where necessary)? This is the
obvious way, but it does mean that the knowledge that this is an
updating operation, which is obvious in the source, is thrown away,
and then has to be reconstructed in the final code generation if this
knowledge enables better code to be generated.
(2) Function calls, especially pure function calls
If a function does not have side effects, then it seems to me that
there is no need for dataflow analysis to give up when it finds a
function call, and so it would help if the design of the intermediate
code facilitated dataflow analysis over function calls. One scheme
which, I think, would work is:
destination 1st operand operation 2nd operand
arglist = make_empty [no operands]
arglist = arglist append arg1
arglist = arglist append arg2
retval = functionname apply arglist
Here all the above operations can be treated like simple arithmetic
operations for the purpose of dataflow analysis.
However, I have not read of this approach anywhere: is there some
hidden snag, or is there a better approach?
(Incidentally, note that 'append' here is another example of the
updating type of operation mentioned above.)
I have read both the Dragon Book and Fischer & LeBlanc, but neither
discusses the topic of intermediate code design very much, rather they
just present an example of an intermediate code without any real
discussion of why they chose the particular operations.
Any pointers to articles or books would be very welcome.
David Stone <firstname.lastname@example.org>
Simoco Europe, P.O.Box 24, St Andrews Rd, CAMBRIDGE, CB4 1DP, UK
Return to the
Search the comp.compilers archives again.