Related articles |
---|
Stack-based IR vs. Register-based IR evan@top.cis.syr.edu (Evan Cheng) (1996-07-20) |
Stack-based IR vs. Register-based IR gough@dstc.qut.edu.au (John Gough) (1996-07-22) |
Re: Stack-based IR vs. Register-based IR patrick_d_logan@ccm.hf.intel.com (Patrick Logan) (1996-07-23) |
Re: Stack-based IR vs. Register-based IR anton@a0.complang.tuwien.ac.at (1996-07-26) |
From: | John Gough <gough@dstc.qut.edu.au> |
Newsgroups: | comp.compilers |
Date: | 22 Jul 1996 10:57:58 -0400 |
Organization: | Compilers Central |
Keywords: | optimize |
evan@top.cis.syr.edu asks ---
> I am hoping to induce some discussion on the merits (or lack of)
> of stack-based intermediate representations and register-based ones.
> Pointers to papers would be much appreciated as well.
We here at gardens point use a stack-based intermediate form, despite
the trend. We do sparc, intel, power, alpha and mips backends based
on these. See http://www.fit.qut.edu.au/CompSci/PLAS/GPM/ for info
on the compilers.
The stack IR itself is defined at
ftp://ftp.fit.qut.edu.au/pub/papers/dcode300.ps.Z
which is version 3.0
We liked stack IRs because of the clean separation between front and
backends, for example, the source of our Modula-2 frontend is identical
in all architectures. We also have a (circa 1988) demo compiler which
interprets the stack IR in the manner of the Java machine. However,
against that should be weighed the fact that our latest backends recreate
a tree form from the stack IR, so that we can use bottom-up-tree-rewriting
for code selection. Yes, this does seem a little ironic, since we started
with a perfectly good AST in the frontend.
John Gough
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.