Re: core changes for mep port

[Ian Lance Taylor <iant at google dot com>]

DJ Delorie <dj@redhat.com> writes:

> > If that is correct, then why do you need these coprocessor modes?
> > For example, why can't you set the mode in struct machine_function
> > and check that when recognizing insns?
> 
> No, it's more like this:
> 
> typedef int copsi __attribute__((mode(COPSI)));
> 
> void foo (int *a, copsi *b, int i)
> {
>   while (i--)
>   {
>     *a *= 2;
>     *b *= 2;
>   }
> }
> 
> This will keep both the core multiplier and the coprocessor multiplier
> busy.
> 
> Since both units run simultaneously, we need two sets of modes, one
> for each unit, so the programmer can indicate which unit each
> operation belongs on.

Well, it's an interesting feature.  And if it only required modifying
the mode support routines I might not worry about it.  But I'm
concerned about the changes to the other files.  I think it's going to
be quite difficult to maintain them over time.  And I think it's going
to be difficult to rip out the support when we drop the MEP.  I find
it very hard to imagine that any other processor is ever going to use
this.

Your example seems a little odd, though I'm sure you have better ones.
Is this a proper type, in that foo must be called with a copsi
argument?  If so, shouldn't we express this in the type system?  If
not, I would find it more natural to express this either by having the
scheduler schedule automatically onto the coprocessor, or by requiring
the use of a builtin function.

I'd be interested in hearing comments from other maintainers.

Ian