Re: Register allocation and instruction scheduling

zalman@netcom.com (Zalman Stern)
27 Jan 1999 13:00:41 -0500

          From comp.compilers

Related articles
Register Allocation and Instruction Scheduling nandu@cs.clemson.edu (1994-03-23)
Register allocation and instruction scheduling mikesw@whiterose.net (1999-01-17)
Re: Register allocation and instruction scheduling greened@zip.eecs.umich.edu (David A. Greene) (1999-01-19)
Re: Register allocation and instruction scheduling bob.morgan@digital.com (1999-01-20)
Re: Register allocation and instruction scheduling greened@zip.eecs.umich.edu (David A. Greene) (1999-01-22)
Re: Register allocation and instruction scheduling bob.morgan@digital.com (1999-01-25)
Re: Register allocation and instruction scheduling mikesw@whiterose.net (1999-01-27)
Re: Register allocation and instruction scheduling zalman@netcom.com (1999-01-27)
Re: Register allocation and instruction scheduling anton@mips.complang.tuwien.ac.at (1999-01-31)
Re: Register allocation and instruction scheduling adrian@dcs.rhbnc.ac.uk (1999-02-01)
| List of all articles for this month |

From: zalman@netcom.com (Zalman Stern)
Newsgroups: comp.compilers
Date: 27 Jan 1999 13:00:41 -0500
Organization: ICGNetcom
References: 99-01-055 99-01-076 99-01-077
Keywords: registers, performance

David A. Greene (greened@zip.eecs.umich.edu) wrote:
: Is this really a problem, though? I was under the impression that
: a processor such as the PA 8K has a maximum number of in-flight
: instructions and the hardware resources such as the instruction
: buffer/reservation stations, execution units and physical registers
: are all tailored to this number.


A good counter example is the PowerPC 604 where a noticeable limit is
that there can only be six outstanding result registers at any given
time. As soon as you try to write the seventh register, the processor
stalls until one of the previous instructions retires. (This comes up
more often than you might expect because PowerPC's load-update
instructions produce two results.) This particularly offended me
because it means code that might run without hazards on an in-order 32
register RISC without renaming can experience stalls on the 604.


Not much for a compiler or human to do about this though. The
processor is pretty much setting a hard limit on the amount of work
you can do...


-Z-


Post a followup to this message

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