Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!ima!dirtydog!suitti From: suitti@ima.isc.com (Stephen Uitti) Newsgroups: comp.arch Subject: Re: Page size and linkers (was: Re: SunMMU history) Message-ID: <1991Feb12.164056.8865@dirtydog.ima.isc.com> Date: 12 Feb 91 16:40:56 GMT References: <45242@mips.mips.COM> <1991Jan27.214522.24408@watdragon.waterloo.edu> <1991Jan29.033024.1516@craycos.com> <1991Feb4.190949.1190@HQ.Ileaf.COM> Sender: news@dirtydog.ima.isc.com (NEWS ADMIN) Reply-To: suitti@ima.isc.com (Stephen Uitti) Organization: Interactive Systems, Cambridge, MA 02138-5302 Lines: 79 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >On 4 Feb 91 19:09:49 GMT, md@HQ.Ileaf.COM (Mark Dionne x5551) said: >md> Simply reordering the .o files helped improve things about 10 to >md> 20%, but structured code tends to put boring initialization routines >md> next to workhorses, etc., preventing one from getting a lot of >md> improvement. pg>I am fond of mentioning another nice idea similar to 'register', and pg>with the same excellent benefits/costs ratio: I have been told that some pg>Algol 68 compiler had a 'rarely' (executed) PRAGMA so that the compiler pg>would generate the relevant code "offline", thus making the most pg>frequently executed path as streamlined as possible. >md> One thing that would help out here would be a compiler switch that would >md> produce multiple .o files for a single .c file (one .o file per function). pg>Actually the better idea is probably to have smart linkers; but, lacking pg>those, this is not a bad idea. I used to be unhappy with the GNU C++ pg>streams implementations, which was very monolithic, so I wrote an pg>implementations that had lots of small source files. Space occupied, and pg>presumably time, decreased dramatically. If you have the compiler generate multiple .o's for .c's, you need some way to tell the linker, "look here first" when resolving symbol addresses. In C, if you reference a function, typically the linker looks for the symbol within the same .o first. If the compiler produces a list of what symbols that were in each .o were global, static, static but relevant to these other .o's, then user's might accidentally obtain more useful libraries. Imagine you are writing a subroutine library. You want function x() to be available to other routines within the library, but you don't want it to be directly available to the caller. If you declare it static, it is only available to other functions within that source file. If you copy it to each source that needs it, you might end up with several copies. If you make your library from all one source, then you may get all sorts of functions linked into the final object that are never referenced. If you can build a library, and say "these are the library external symbols", using a list that is perhaps outside of the C sources, then you can build better libraries. If it is easy to do, maybe more libraries will be built. For that matter, sometimes it is more convenient to stuff lots of functions into a single source file. It'd be real nice if the functions that aren't referenced aren't linked into the user's application. Again, if it is easy (or free) to do it right, more programmers will do it right. A smart linker could do the reordering, or even dead function elimination, but an optional external list would make library writing easier to do right, and bullet proof libraries could be built. One of the first interesting debugging exercises I witnessed had to do with a novice C user, who typed in the "index()" function in the K&R C book. He was amazed that I/O no longer worked right. The K&R index() took two string arguments. The libc version takes a string and a character. Somewhere in stdio, index() was invoked. Since the user had already defined it, the linker didn't load the libc version... Imagine if the linker were smart enough to know that libc should be hooked up to the libc version of "index()", and the user's code should be hooked up to his/her own version of "index()". I've heard that some big company, GM or someone, has done something like this. Whoever it was hasn't released it for the world. We need people who publish software to do it. Then we could start working for world peace or something. Stephen. suitti@ima.isc.com "We Americans want peace, and it is now evident that we must be prepared to demand it. For other peoples have wanted peace, and the peace they received was the peace of death." - the Most Rev. Francis J. Spellman, Archbishop of New York. 22 September, 1940