Stack-based IR vs. Register-based IR

John Gough <gough@dstc.qut.edu.au>
22 Jul 1996 10:57:58 -0400

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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