|[2 earlier articles]|
|Re: Compiler Optimizing assembler email@example.com (1996-11-03)|
|Re: Compiler Optimizing assembler firstname.lastname@example.org (David L Moore) (1996-11-03)|
|Re: Compiler Optimizing assembler email@example.com (1996-11-05)|
|Re: Compiler Optimizing assembler Martin.Ward@durham.ac.uk (1996-11-05)|
|Re: Compiler Optimizing assembler firstname.lastname@example.org (K. Sridharan) (1996-11-07)|
|Re: Compiler Optimizing assembler email@example.com (Walter Banks) (1996-11-07)|
|Re: Compiler Optimizing assembler firstname.lastname@example.org (1996-11-10)|
|From:||email@example.com (Shankar Unni)|
|Date:||10 Nov 1996 15:41:18 -0500|
|Organization:||Chromatic Research, Sunnyvale, CA|
David L Moore (firstname.lastname@example.org) wrote:
> The MIPS compiler team did some optimization in the assembler. If
> memory serves, they also had some profiling based optimization in the
> linker to reduce code working set sizes by packing machine code into
> pages based on call patterns. These people are now presumably at
> Silicon Graphics.
The MIPS assembler does only some very basic optimizations (peephole-type).
It really doesn't do any "high-level" optimizations on the code.. The
profiling-based "optimizer" you list is "cord" (a code rearranger) that
uses profile data to rearrange the order of entire functions in an
executable so as to minimize paging.. The MIPSpro 7.0 compilers (new) have
some support for true profile-based optimizations in the compiler itself.
HP's compilers also have features like this. I seem to remember that the HP
assembler actually goes "up" to one of the lower levels of the optimizer
(their compilers normally generate object files directly - the assembler
reads source and plugs into one of the lowest levels of the optimizer,
above the code generator). They also do profile-based optimizations *in
Shankar Unni email@example.com
Chromatic Research (408) 752-9488
Return to the
Search the comp.compilers archives again.