Need advice on interface to non-gcc scheduler

[Marko Mlinar]

Steven,

I am Marko Mlinar, co-developer of OR2k, mentioned before.
Let me say that I am surprised too, that our designs have so much
similarities. Besides I don't think those three points
you mentioned aren't really differences except second one.
You even used 4 as a number of neigbours like we did.
And optimization algorithm is really similar to one we used.
(even heuristics proposed in article; well - later we used more
complex ones, that produced better results).
Have you made any simulations? We have already made several.

I wonder - do you intend to use such arhitecture for general purpose
computing or just for applications that needs high computation power?
How do you intend to apply jumps/calls to your arhitecture?
Major differences I see are:
1. your design uses (more) centralised register file, which may cause
    problems, especially with jumps and calls; maybe localised register
    file (as you mentioned it) and as we use it may put us to same ground
2. your use more 'localised' connections this may cause problems with
    larger number of units, but on the other hand dataflow graph may be
    much more easily extracted.

I suggest that you use more specialised algorithm based on dataflow tree
extraction (place small parts of df tree into 2D (unit,time) space), which
could have much lower complexity and could yield better results.
(I am just speculating based on my experiences - I have nothing concrete
in mind yet).

I belive (based on my simulations), that algorithms doesn't work so
well for large number of units (like >10).


best regards,
    Marko

----- Izvorno sporoèilo -----
Od: Damjan Lampret <lampret@opencores.org>
Za: <gcc@gcc.gnu.org>
Kp: Marko Mlinar <Marko.Mlinar@campus.fri.uni-lj.si>
Poslano: 31. marec 2000 23:54
Zadeva: Re: Need advice on interface to non-gcc scheduler


> Steven,
>
> I am also surprised with similarities between both architectures. Our
> approach would be similar to yours except in our case we were thinking to
> use assembly output for some generic RISC as input to "optimizer" for
OR2K.
> BTW FUs in OR2K doesn't need to be equal since some instructions are more
> common than others.
>
> regards, Damjan
>
> ----- Original Message -----
> From: Steven Roos <        >
> To: <gcc@gcc.gnu.org>
> Sent: Friday, March 31, 2000 3:59 PM
> Subject: Re: Need advice on interface to non-gcc scheduler
>
>
> > "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.