15 ms·

I am not sure I totally get the author's point. Many commercial compilers had already implemented and shipped many of the optimizations later found in GCC befor

I am not sure I totally get the author's point. Many commercial compilers had already implemented and shipped many of the optimizations later found in GCC before GCC did, although these compilers were often for a different class of machine than the average desktop Linux PC. Is he saying that GCC implemented them just as they became viable on lower end hardware?

derleth 15y ago
> Is he saying that GCC implemented them just as they became viable on lower end hardware? To begin with, gcc didn't target low-end hardware; low-end hardware of 1985 (the beginning of the GNU Project) wasn't capable of running serious OSes, so Stallman ignored it in favor of workstations built around Motorola 68000 CPUs (I believe). But that's beside the point: He's saying that once lower-end systems began to be as capable of the optimizations as high-end systems were previously, the expectations of compilers for low-end systems began to match the expectations of compilers for high-end systems. He's also implicitly making the point that, once CPU speed is above a certain minimum, the thing that most limits a computer is a shortage of RAM. A compiler for an MS-DOS system with a few hundred K of RAM can't do advanced register scheduling (not that the 8088 has a lot of registers to begin with) or code transformations but that's OK, because nobody expects it to. All people expect is for their Borland Pascal or Pacific C or whatever compiler to emit machine code that correctly implements their algorithm and, if it's a bit slow, they'll grab Ralf Brown's Interrupt List and other reference material and start hacking assembly. In Linux, in 2011, people expect gcc to not only correctly unroll loops, but to transform recursive functions into an iterative form and then unroll the resulting loop. (gcc can, actually, do this.) They expect gcc to use MMX opcodes in somewhat-ingenious ways to speed up string handling; and as an aside most of the more interesting opcodes of the x86 ISA are another thing the solo MS-DOS hackers didn't have to worry much about until near the end of the MS-DOS era. They expect, in short, a compiler that would have been at home on a very high-end system as recently as the early 1990s and is therefore too complex for any single human to write unaided. (Well, perhaps Knuth could, but Knuth doesn't scale.)

derleth 15y ago

> Is he saying that GCC implemented them just as they became viable on lower end hardware? To begin with, gcc didn't target low-end hardware; low-end hardware of 1985 (the beginning of the GNU Project) wasn't capable of running serious OSes, so Stallman ignored it in favor of workstations built around Motorola 68000 CPUs (I believe). But that's beside the point: He's saying that once lower-end systems began to be as capable of the optimizations as high-end systems were previously, the expectations of compilers for low-end systems began to match the expectations of compilers for high-end systems. He's also implicitly making the point that, once CPU speed is above a certain minimum, the thing that most limits a computer is a shortage of RAM. A compiler for an MS-DOS system with a few hundred K of RAM can't do advanced register scheduling (not that the 8088 has a lot of registers to begin with) or code transformations but that's OK, because nobody expects it to. All people expect is for their Borland Pascal or Pacific C or whatever compiler to emit machine code that correctly implements their algorithm and, if it's a bit slow, they'll grab Ralf Brown's Interrupt List and other reference material and start hacking assembly. In Linux, in 2011, people expect gcc to not only correctly unroll loops, but to transform recursive functions into an iterative form and then unroll the resulting loop. (gcc can, actually, do this.) They expect gcc to use MMX opcodes in somewhat-ingenious ways to speed up string handling; and as an aside most of the more interesting opcodes of the x86 ISA are another thing the solo MS-DOS hackers didn't have to worry much about until near the end of the MS-DOS era. They expect, in short, a compiler that would have been at home on a very high-end system as recently as the early 1990s and is therefore too complex for any single human to write unaided. (Well, perhaps Knuth could, but Knuth doesn't scale.)