Need advice on interface to non-gcc scheduler

[Steven Roos]

"Damjan Lampret" <lampret@opencores.org> wrote:
> Hi Steven,
> 
> is your architecture similar to something like
> http://www.opencores.org/cores/or2k/ ?

The philosophy behind the architecture is more or less the same, but
on the implementation level there are some differences. The three most
important differences are:
1. We use a one-dimensional array instead of a two-dimensional matrix
   because we think that would map better onto hardware.
2. We allow only Ri (the only non-locally visible register on a unit)
   as the destination of an operation.
3. Our FUs are not all equivalent because we think the hardware
   required for some opcodes like multiply is too expensive to be
   included in each unit.

However, even with these differences the similarities are remarkable.
Unfortunately I do not have a recent architecture description. The
paper http://cardit.et.tudelft.nl/MOVE/papers/Roos99a.ps.gz gives
a good introduction, but is in many ways outdated. For example, it
does not yet include the concept of a local register file in each
unit.

> I've tried to model OpenRISC 2000 in
> GCC but GCC doesn't understand very good concept of distributed register
> file. I've tried this with register classes defining a new register class
> for each functional unit and its registers. Of course since GCC was designed
> for traditional CPUs where you have one central register file it does not
> generate efficient code for CPU similar to OR2K. I would be interested if
> anyone has better idea how to model OR2K in GCC so that GCC would generate
> efficient code?
> 
> regards, Damjan

I haven't found any compiler that can effectively handle the
non-homogeneous and distributed register files as found in OR2K and my 
architecture. Most compilers (including gcc) try to assign a single
register to the complete liverange of a variable and fail to
distribute instructions and data evenly over the processor.

Therefore I have put down a completely new scheduling algorithm that
is capable of handling such register file topology. I think it can
also schedule for OR2K with very limited modifications. It requires a
completely new scheduler module, with its own internal representation.
My idea is to use gcc with a RISC-like target as a front-end and
switch my own module for the scheduling and register allocation.

Regards,
Steven