List-scheduling: a RISC-driven solution?

Mayan Moudgill <moudgill@cs.cornell.EDU>
Tue, 11 May 1993 17:14:52 GMT

          From comp.compilers

Related articles
List-scheduling: a RISC-driven solution? moudgill@cs.cornell.EDU (Mayan Moudgill) (1993-05-11)
Scheduling for RISCs: more on List-scheduling moudgill@cs.cornell.EDU (Mayan Moudgill) (1993-05-19)
Re: List-scheduling: a RISC-driven solution? (1993-05-26)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Mayan Moudgill <moudgill@cs.cornell.EDU>
Keywords: optimize, comment
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Tue, 11 May 1993 17:14:52 GMT

On most architectures, the compiler has to satisfy 3 constraints when
scheduling instructions:
      -- Registers
      -- Functional Units/Issue Latency
      -- Issue Slots

On a typical RISC architecture with 32 registers, and single cycle (or
low) latency functional units, the main constraint becomes the issue slot.
Typically, an architecture can issue only one instruction per cycle. Any
scheduling algorithm that manages to schedule so that at least one
instruction is issued every cycle will do well.

An interesting phenomen:
    * Graph coloring was published in '81.
    * RISC ideas were published around '80.
    * All work on non list scheduling based scheduling algorithms ceased to be
          published around then.
    * The only work that I know of in the 80--90s era that is NOT list-schedule
          based is the stuff done by the Cydra group for their VLIW computer.

Would anyone care to agree/disagree with me? I would be _extremely_
interested to find any pointers to scheduling papers in the period 79-92
inclusive that do NOT use list scheduling.


P.S. Much of this information was gleaned from talking with Richard Huff.
However, I am the one responsible for the phrasing and the questions in
this article.
[Did Cydra use the Multiflow compiler or is it something else? -John]

Post a followup to this message

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