|MIPS optimizing compiler email@example.com (1997-08-28)|
|Re: MIPS optimizing compiler firstname.lastname@example.org (1997-08-30)|
|Re: MIPS optimizing compiler email@example.com (1997-08-30)|
|Re: MIPS optimizing compiler firstname.lastname@example.org.OZ.AU (1997-09-03)|
|Re: MIPS optimizing compiler robert.wilson@Eng.Sun.COM (Bob Wilson) (1997-09-07)|
|Link time optimization (was: MIPS optimizing compiler) email@example.com (1997-09-07)|
|Date:||30 Aug 1997 00:49:51 -0400|
|Organization:||SimGraphics Engineering, South Pasadena, California|
Bjorn De Sutter <firstname.lastname@example.org> wrote:
>I'm starting my research on optimzing linkers. I read in a Ph.D thesis
>that the highest optimization flag on the MIPS compiler, would enable
The SGI/MIPS "optimizing linker" is a big failure. Briefly: compiler
would produce *.u files with intermediate code instead of object code
*.o; linker would link *.u files, and then run a global code
generator/optimizer to produce a.out executable. Libraries of *.u
code could be made in *.b format, similar to *.a for *.o.
SGI has been pushing this for a while, till about 1995. It never
really worked, in the sense that SGI never would ship any of their
proprietary code in the *.u or *.b format.
About 3-4 years ago SGI internaly recognized hopelessness of that
technology, and put all of the resources into development of new
MIPSpro family of compilers, which have run-of-the-mill design. The
old technology (ucode) is still maintained as far as bug fixes.
You may want to go to http://techpubs.sgi.com and look through IRIX
5.3 manuals. Please remeber that you will be doing grave digging,
Optimizing linker doesn't yield itself to modern technology of
producing bloatware. Dynamic shared objects are the game where all the
current interest goes.
Good luck in your research,
Return to the
Search the comp.compilers archives again.