|Stack-based IR vs. Register-based IR firstname.lastname@example.org (Evan Cheng) (1996-07-20)|
|Stack-based IR vs. Register-based IR email@example.com (John Gough) (1996-07-22)|
|Re: Stack-based IR vs. Register-based IR firstname.lastname@example.org (Patrick Logan) (1996-07-23)|
|Re: Stack-based IR vs. Register-based IR email@example.com (1996-07-26)|
|From:||John Gough <firstname.lastname@example.org>|
|Date:||22 Jul 1996 10:57:58 -0400|
email@example.com 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
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.
Return to the
Search the comp.compilers archives again.