Jupming in at a random point. First, unless my memory is completely faulty, Stan Cox should be named in this change too. ISTR he did the initial implementation for one particular coprocessor, which we later generalised to cover other user- configurable coprocessors. However, as DJ says, it's been a long time, so I might have got that wrong.
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > So far, so good. But: if I understand the patch, in order to use the > coprocessor, the user must write their code using special types. Is > that an important and desirable feature? Or is that taking the fact > that the compiler doesn't know how to handle register allocation and > scheduling for this processor and pushing the problem onto the user? For the record, the programmer's view of MeP-specific parts was specified by Toshiba, and IIRC is compatible with their own MeP compiler. And it does seem like a reasonable feature to want in some form. The MeP is a configurable processor, and the user in general has a lot of control over how the coprocessor behaves. So, although I have no direct experience of developing MeP-based products, I imagine that the development of the code and development of the processor go hand-in-hand. If the first cut isn't quite what you'd hoped for, you might want to tweak the partition of your core loop, or you might want to tweak the coprocessor. Both should be under uesr control. Of course, giving the user the ability to specify this manually doesn't mean that an automatic partitioner wouldn't be useful too. So to answer your last question: I think it was designed as something that would be independently useful, rather than as something that had no other purpose than to avoid hacking a compiler. And it seemed quite easy to use in practice. Richard
