jan@gun.neuroinformatik.ruhr-uni-bochum.de (JAN VORBRUEGGEN) (01/30/91)
I found the recent summary of the code-generation quality of C compilers for transputers very interesting. (In fact, I was astonished that the preliminary posting had generated so little response. Everybody stunned into silence by the results??) Of course, the obvious question now is: How can the situation improve? I think we need two things: 1. A sensible C front-end that does all the high-level language-specific things like constant folding and propagation, loop hoisting und unrolling etc. Maybe the GNU C compiler is a sensible starting point for this? 2. A sensible transputer back-end that does a good job of generating efficient code for transputers. Probably anything in existance won't do, because most code-generators (eg, the GNU one) are geared toward the usual register-based machines. And don't tell me INMOS' code-generator is much better! I've looked at enough of the code produced by the occam compiler to know that it could do improve a lot. (occam has the advantage that you can express your a priori knowledge in a nice, clean way (eg, via abbreviations), and the compiler does take advantage of this.) And anything one were to produce now would have to cope with the substantial changes required for the new chips. But maybe somebody could be found to produce such a beast. Perhaps even INMOS, though they would have to relinquish some of their erroneous misconceptions they hold dear about the preformance of their own product... Just for the record: I do like transputers, and I do like occam. I just think it's a shame we're treated to compiler quality of about 20 years back on what's supposed to be a 'leading edge' product. And what does it help when I know it's a 2 Mflops processor (because my assembler routines can do it), but the equivalent C is cited at 0.13 M? Jan Vorbrueggen, Institut f. Neuroinformatik Uni Bochum, FRG jan@bun.neuroinformatik.ruhr-uni-bochum.de