Your historical info is only partly accurate. You are right about the beginning part. In the beginning there was MIPS, and MIPS wrote a toolchain that tried to be friendly to assembly language programmers. Because of this, some optimizations, mainly instruction scheduling and delay-slot filling, were implemented in the assembler instead of the compiler, so that they would be usuable to assembly language programmers. Since gcc/binutils usually follows conventions set by the vendor, gcc/binutils did things the same way. Later, gcc started using its own instruction scheduler and delay-slot filling optimization passes, but we never fully moved away from relying on assembler optimizations. >The first GCC ports for MIPS were quick hacks using the MIPS >assembler. They made liberal use of what were effectively macro >instructions. I think this is inaccurate in a number of ways. It is a gcc convention to use the native assembler whenever possible, and be compatible with the native assembler language. We write our own assembler only when the native one isn't good enough to bootstrap gcc, or when there is no other native assembler, e.g. embedded and linux targets. Similarly, we create our own assembler language only when there isn't an existing one we can use. So there was nothing wrong with using the MIPS/SGI assembler for the original gcc ports. Also, gcc followed the conventions set by the MIPS/SGI compilers, which used macro instructions very heavily. Thus gcc used macro instructions heavily also. In hindsight this was a mistake, but at the time it wasn't so obvious. >Which got a whole lot worse when gcc/gas was hacked again for position >independent code and the bulk of that work was done in the assembler. I agree everything got a lot uglier when PIC support was added. However, it was SGI that did it first in the assembler, and gcc/gas just followed exactly the conventions that were defined and implemented by SGI, in order to maintain compatibility with SGI systems. When we added PIC support for embedded systems, it was just more of the same. >But getting the assembler macros out of the compiler is a long-overdue >reform. Definitely. SGI eventually realized their original toolchain design was limiting their performance, and when SGI introduced their 64-bit Irix6 workstations, they used this as an excuse to write a new compiler from scratch in which all optimizations were performed in the compiler, and no assembler optimizations were used at all. Gcc has unfortunately not made the switch over yet, but people are working on it. Once again, we are following conventions defined by SGI. Jim
