Re: Compilers and RISC (was: '040 vs. SPARC)

In article <1990Feb11.040548.223@esegue.segue.boston.ma.us>, dgb@cs.washington.edu (David Bradlee) writes:
>
> > I do see one *possible* advantage accruing from all of this, though, which
> > is that instruction scheduling, delay slot filling, and register
> > allocation may be somewhat more machine independent in concept and more
> > amenable to being table driven across architectures than instruction
> > selection generally proves to be.
>
> This is probably true for register allocation by itself, given that RISCs
> typically have general purpose register sets, but it remains to be seen
> for instruction scheduling and for the combination of the two. Part of
> the problem is the specification of the information needed for scheduling
> (especially for something like the i860).




Actually, instruction scheduling, delay slot filling and register allocation
*are* all concepts that can be dealt with in an architecture independent
manner. Without sounding too much like a salesman ;-), the QTC Software
Foundry tool suite does just that. Each architecture is configured by
defining the syntax and semantics of each instruction within the architecture.
This included information such as the number of cycles of delay for a
MUL instruction to deposit the result in the destination register. It can
also define which resources each instruction uses, and whether the
units are pipelined.


The SF/Optimizer then reads this configuration database, and performs
software pipelining and basic block compaction and register reallocation
(to free too restrictive data dependencies) on the "configured" architecture.
We have done this very technique for a number of VLIW custom bit-slice
processors, and have configured the tools for the i860, 80960CA and 88000
(these in "targeted" SF/Scheduler products).


> Then there's the question of whether a particular scheduling technique will
> be good enough for all your desired targets. Perhaps not.


This is a good point. Certainly, this method is a shoo-in for some
architectures, but others tend not to be able to achieve theoretical
minimum loop sizes automatically. To take steps toward solving this problem,
we created an interactive mode on the SF/Optimizer that is a windowed
environment and knows all the rules you specified in the configuration.
It allows you to move instructions into a better parallel placement, while
it reminds you of data dependency rules (the data dependency graph is
shown as well as register live tracks) and other programming rules that
cannot be broken. This way, the programmer can beat the heuristic based
tool, and yet the tool is helping keep track of pitfalls.


-- Dave Glass


| David N. Glass ...ogcvax
| Quantitative Technology Corp. ...verdix !qtc!glass
| 8700 SW Creekside, Suite D ...sequent
| Beaverton, OR 97005
| (503) 626-3081

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