jnh@ece-csc.UUCP (Joseph Nathan Hall) (04/18/89)
In article <7021@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >First, MPW C 3.0 is supposedly a pretty smart optimizer. Second, I >don't agree. Any good compiler can create reasonably good code for a >simple loop of this kind. With an old C compiler, you may have to use >register declarations, but there's no reason a compiler can't produce >code as good as assembler for a "for" loop. Is that so? Well, sure, in *theory* it's possible, but in practice it takes time to translate computer science into workable products. (With the weird exception of the retargetable GNU compiler.) I doubt you'll see a workable, aggressively optimizing "C" compiler on the Mac in less than another two years. After all, such a compiler requires a couple of meg of some kind of memory to run in ... how long have 2Mb Macs (not Lisas) been commonplace? About a year ... A debugged optimizing compiler takes a couple of years (or more) to produce in a known programming environment. The Mac is *hardly* the easiest, most conducive environment for compiler-writing. As an aside, witness the lousy RISC compilers in existence today. Sure, you get three times the MIPS out of a RISC processor as a same-size CISC processor ... but then the compiler produces 2-3 times as much code. And of course you can always tighten up CISC code by hand... It'll be another year or two before decent commercial RISC compilers are generally available--at least. >(I refuse to use register >declarations in 1989; the techniques of register optimization have been >well understood for more than a dozen years now, and a compiler that >doesn't use them is brain damaged. I'm only using LSC now because my >client preferred it.) Well, whenever *I* find a portable method of (probably) increasing the execution speed of my programs, *I* try to use it when it's appropriate. The worst kind of compiler brain damage, so far as I'm concerned, is improper compilation; the second worst is gratuitous non-standard-ness. If a compiler has none of the first, it's at least usable. If it has none of the second, it's REALLY usable. Who gives a damn how tight the code is if the compiler's flaky? LSC does a pretty poor job of optimization, I'll admit, but the inline assembler and I do an excellent job in the very few places it's required. LSC will only get better in this respect. It seems silly to me to disparage the fastest- and easiest-compiling "C" compiler available for the Mac because it fails to produce generally tight code, especially when assembly language programming on the Mac is still widely supported and (sometimes) encouraged. I'd much rather disparage it for its bungled non-handling of prototype declarations ... but that's another story. -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || joseph@ece007.ncsu.edu (Try this one first) -----------|| Standard disclaimers and all that . . . . . . . . . . . . . .