DJ Delorie <[EMAIL PROTECTED]> 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
