Path: utzoo!attcan!uunet!snorkelwacker!spdcc!ima!esegue!compilers-sender
From: pd@complex.Eng.Sun.COM (Peter C. Damron)
Newsgroups: comp.compilers
Subject: Re: Intermediate Representation
Keywords: code, optimize, design
Message-ID: <1990Aug15.144513.6992@esegue.segue.boston.ma.us>
Date: 15 Aug 90 14:45:13 GMT
References: <1990Aug08.171640.13892@esegue.segue.boston.ma.us> <1990Aug09.180627.18848@esegue.segue.boston.ma.us> <1990Aug9.225859.10175@rice.edu>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: pd@complex.Eng.Sun.COM (Peter C. Damron)
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 33
Approved: compilers@esegue.segue.boston.ma.us

I think that the discussion of intermediate representations has
centered too much on the abstract structure of the IR.

There are 3 pieces that I can think of to an IR:
1. The abstract machine model
2. The operators and their semantics
3. The abstract structure (AST, 3-address, PDG, etc.)

I would say that #1 and #2 are more important than #3 in determining
how hard it is to optimize over that IR.

For #1, the usual choices are either a stack machine, or a register
based stack machine.

For #2, I'm not sure that there is much of a consensus about what
the best set of operators is.  Any thoughts?

What about "ROSIR" -- reduced operator set intermediate representation?

Just a thought,
Peter.

----------------------------
Peter C. Damron
Sun Microsystems, Inc.
Advanced Languages, MS 12-40
2550 Garcia Ave.
Mtn. View, CA  94043

pdamron@eng.sun.com
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.