From mboxrd@z Thu Jan  1 00:00:00 1970
From: forsyth@caldo.demon.co.uk
To: 9fans@cse.psu.edu
Subject: Re: [9fans] p9/linux/fbsd compiler shootout
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20020226105950.D68B719A05@mail.cse.psu.edu>
Date: Tue, 26 Feb 2002 11:15:32 +0000
Topicbox-Message-UUID: 5621d2ec-eaca-11e9-9e20-41e7f4b1d025

>>GCC had to develop a whole special extra codegen unit to manage to do
>>fp on a 386 anything approaching well, and without something like
>>that, it's pretty painful.

the code generators are all custom, although the RISC ones are similar
(and closely related), so that aspect of the peculiar floating-point
isn't troublesome (which isn't to say it tries anything too fancy).
the 680x0 and x86 compilers have a lot of custom code.

the plan 9 c compilers aren't like pcc, which did a simple essentially
one-pass translation (to assembler) with no optimisation.
the compiler does function-level register allocation, addressing mode selection
and broad instruction selection, with local code improvements.
unusually, detailed (machine-level) instruction selection is done by
the linker (which is in a good position to do ARM/Thumb linkage, literal pools,
span-dependent instructions, instruction scheduling, etc.).  only the linker knows
the binary formats of instructions of a given processor or processor variant.
some instructions issued by the compiler don't correspond to real instruction variants.
the assembler is just a front-end to the linker.  the compiler doesn't use the assembler.