Re: Intermediate Representation

hankd@dynamo.ecn.purdue.edu (Hank Dietz)
Sun, 12 Aug 90 13:50:18 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Intermediate Representation preston@rice.edu (Preston Briggs) (1990-08-08)
Re: Intermediate Representation mod@westford.ccur.com (Michael O'Donnell (508)392-2915) (1990-08-09)
Re: Intermediate Representation grover@brahmand.Eng.Sun.COM (1990-08-09)
Re: Intermediate Representation preston@titan.rice.edu (1990-08-10)
Re: Intermediate Representation larus@primost.cs.wisc.edu (1990-08-12)
Re: Intermediate Representation grover@brahmand.Eng.Sun.COM (1990-08-12)
Re: Intermediate Representation hankd@dynamo.ecn.purdue.edu (1990-08-12)
Re: Intermediate Representation jouvelot@brokaw.lcs.mit.edu (1990-08-12)
Re: Intermediate Representation convex!csmith@uunet.UU.NET (1990-08-12)
Re: Intermediate Representation preston@titan.rice.edu (1990-08-13)
Re: Intermediate Representation preston@titan.rice.edu (1990-08-13)
Re: Intermediate Representation jouvelot@brokaw.lcs.mit.edu (1990-08-13)
Re: Intermediate Representation marti@antares.inf.ethz.ch (1990-08-13)
[10 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: hankd@dynamo.ecn.purdue.edu (Hank Dietz)
In-Reply-To: <1990Aug08.171640.13892@esegue.segue.boston.ma.us>
Keywords: code, optimize, design
Organization: Purdue University Engineering Computer Network
Date: Sun, 12 Aug 90 13:50:18 GMT

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)...?
--


Post a followup to this message

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