On Nov 17, 2005, at 21:33, Dale Johannesen wrote:
When I arrived at Apple around 5 years ago, I was told of some recent
measurements that showed the assembler took around 5% of the time.
Don't know if that's still accurate. Of course the speed of the
assembler
is also relevant, and our stubs and lazy pointers probably mean
Apple's
.s files are bigger than other people's.
Of course, there is a reason why almost any commercial compiler writes
object files directly. If you start feeding serious GCC output through
IAS (the Intel assembler) on a platform like IA64, you'll find that this
really doesn't work. A file that takes seconds to compile can take over
an hour to assemble.
GCC tries to write out assembly in a way that is unambiguous, so
the exact instructions being used are known. Any platform with a
"smart optimizing", assembler will run into all kinds of issues.
(Think MIPS.) Many assembler features, such as decimal floating-point
number conversion, are so poorly implemented that they should be avoided
at all cost. Some assemblers like to do their own instruction splitting,
NOP insertion and dependency detection, completely throwing off choices
made by the compiler's scheduler. Then there is alignment of code
labels.
If there even is the slightest doubt about what exact instruction
encoding the assembler will use, all bets are off here too.
If you'd start from scratch and want to get everything exactly right,
it seems clear that the assembly output path is far harder to implement
than writing object code directly. When you know exactly what bits you
want, just go and write them. However, given that all ports are
implemented based on assembly output, and that many users depend on
assembly output being available, changing GCC's ways will be
very labor intensive unfortunately.
-Geert
