Re: Is register stack compilers' friend?

stevec@pact.srf.ac.uk (Stephen Clarke)
Mon, 6 Nov 1995 18:52:37 GMT

          From comp.compilers

Related articles
Is register stack compilers' friend? jaidi@technet.sg (1995-10-31)
Re: Is register stack compilers' friend? hbaker@netcom.com (1995-11-04)
Re: Is register stack compilers' friend? cliffc@ami.sps.mot.com (1995-11-05)
Re: Is register stack compilers' friend? stevec@pact.srf.ac.uk (1995-11-06)
Is register stack compilers' friend? dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-06)
Re: Is register stack compilers' friend? paulb@pablo.taligent.com (1995-11-09)
Re: Is register stack compilers' friend? jeremy@suede.sw.oz.au (1995-11-13)
| List of all articles for this month |

Newsgroups: comp.compilers
From: stevec@pact.srf.ac.uk (Stephen Clarke)
Keywords: architecture, design
Organization: University of Bristol, England
References: 95-11-026
Date: Mon, 6 Nov 1995 18:52:37 GMT

Nor Jaidi (jaidi@technet.sg) wrote:
: I would like to hear from anyone having experience with writing compilers
: for transputer. Register stack Vs large register file: which is better for
: the compiler?


The major advantage of the transputer's expression stack architecture
is that it gives dense instruction coding, as operand locations are
implicitly on the top of the stack, rather than in explicitly coded
registers. I don't think there's any great difference in ease of
code generation (I'm not including optimization here) between the
transputer's expression stack and a machine with a general register
set: for the expression stack you have to be careful about not
exceeding the fixed stack depth (the stack is only three deep on the
transputer), and for a general register set, you have to be careful
about not exceeding the number of registers available (of course,
lots of compilers generate for an infinite virtual register set and
then worry about mapping virtual registers to real registers later
on; similarly, some compilers for the transputer generate for an
infinitely deep expression stack and then fix up the code later on).


John is correct: optimizing is hard. In the ST compilers, we use a
three-address intermediate code, do all the standard global
optimisation at this level, and then later on generate stack code.
The transformation to stack code is fairly straightforward Red Dragon
stuff: generate a DAG from the three-address code, partition the DAG
into trees, and then generate the stack code from the trees. (Other
transputer compilers generate stack code directly from the DAG.)
This transformation has the side-effect of keeping values on the
expression stack where possible. The transputer doesn't have all the
fancy swap, rotate etc. so there isn't much scope for tricks to keep
the right value on top of the stack - there is a dup instruction, but
apart from that, if you need to keep a value around for more than one
use, you have to spill it and reload it later.


We do use a colouring algorithm in our compiler, but this is to allocate
the stack frame (some transputers cache the top of stack, so it can be of
benefit to ensure that frequency used values hit this cache).


Stephen Clarke
-------------
SGS Thomson Microelectronics
Chameleon Programme - Software Group
Email: stevec@bristol.st.com
Mail : 10 Priory Road, Clifton, Bristol, BS8 1TU. UK.
Phone: +44 117 970 7188, Fax +44 272 707 171.
--


Post a followup to this message

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