Re: Intermediate Representation

In article <1990Aug08.171640.13892@esegue.segue.boston.ma.us>:
>In article <1990Aug07.153407.8877@esegue.segue.boston.ma.us>:
>>(1) Abstract-syntax-tree (looks like Scheme code)
>>(2) DAG
>>(3) Three address code
>>(4) P-code
>>(5) Stanford's U-code
>
>First, I'd classify (5) as an extension of (4) and I might group (2) with
>(3).
>
>I like low-level 3-address code (even lower level than assembly).


I agree 100%. BTW, (3) is a walk embedding (2). Catch is that (1) is
easier to automate, so, for example, PCCTS is headed that direction....


>AST's seem too high-level for doing lots of optimization. We want the
>details of array accesses, etc. exposed to the optimizer.


You're making an assumption here that simply doesn't hold... the AST
elements need not be *just* the syntax elements from program, but can
be any transformation thereof. In other words, it can be quite low
level, just like code tuples.


>[Anybody tried program dependency graphs, per Ferrante et al. at IBM. From
>the articles I've seen, they look pretty neat. -John]


Yes and no. We've played with a similar form for automatic parallelization
at the process packaging stage, but it doesn't work so well for some
lower-level things.... The truth is that most optimizing, parallelizing,
compilers use several different intermediate forms which are all
interconnected (one form annotates another). No big deal... that is,
unless you want to print out a program's intermediate form
representation.... :-)


-hankd@ecn.purdue.edu


PS: Why is there a gratuitous ref to Scheme in (1)...?
--

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