Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Page size and linkers (was: Re: SunMMU history) Message-ID: Date: 13 Feb 91 19:49:53 GMT References: <45242@mips.mips.COM> <1991Jan27.214522.24408@watdragon.waterloo.edu> <1991Jan29.033024.1516@craycos.com> <1991Feb4.190949.1190@HQ.Ileaf.COM> <1991Feb12.164056.8865@dirtydo Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 67 Nntp-Posting-Host: odin In-reply-to: suitti@ima.isc.com's message of 12 Feb 91 16:40:56 GMT On 12 Feb 91 16:40:56 GMT, suitti@ima.isc.com (Stephen Uitti) said: suitti> In article suitti> 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> One thing that would help out here would be a compiler switch that md> would produce multiple .o files for a single .c file (one .o file md> per function). pg> Actually the better idea is probably to have smart linkers; but, pg> lacking those, this is not a bad idea. I used to be unhappy with the pg> GNU C++ streams implementations, which was very monolithic, so I pg> wrote an implementations that had lots of small source files. Space pg> occupied, and presumably time, decreased dramatically. suitti> If you have the compiler generate multiple .o's for .c's, you suitti> need some way to tell the linker, "look here first" when suitti> resolving symbol addresses. In C, if you reference a function, suitti> typically the linker looks for the symbol within the same .o first. suitti> If the compiler produces a list of what symbols that were in each suitti> .o were global, static, static but relevant to these other .o's, suitti> then user's might accidentally obtain more useful libraries. This is true -- you need to add a new visibility distinction, whether an entitity is visible only within or also outside a library. This can be hacked by tweaking appropriately the format of the symbol table in .a files. Incidentally, I think that instead of having the assembler compiler generate multiple .o files, it would be nice for it to generate a single .a file. It would not be difficult to modify GNU to have a suitable -a option, as in 'gas -a many-functions.a many-functions.s'. But really the root problem is that we are discussing a language like C and its three visibility levels, and other aspects which were designed around linking technology straight out of the the fifties. The inertia of masses of C applications and of linkers designed exactly as they were in the fifties is tremendous, as C++ users discover to their detriment. It is deeply ironic that most hardware designers have read something at least on Multics and have put hooks for modern linking technology and languages in the interior decors of most modern systems, even if most OSes and nearly all incarnations of Unix simply do not use them! Only recently SunOS and SVR4 have acquired some hacky dynamic linking technology, for example. This tragedy is almost as great as that of millions of 286s runnin DOS when they have protected mode rings and virtual memory and features straight out of Multics or TSS/370. There are some languages that are designed under the impression that the evolution of linker technology has not stopped with the 7090 or the 1100 or the 600, and that make use of linkers deign of the early sixties, for example Modula2 and Ada. There are even languages that assume linking technology as it evolved in the seventies, but I know of no mainline system that uses it. It could be said that many languages in the Scheme, Lisp, Poplog family have linking technology out of the seventies, but they are hardly as popular as they should be. Ah architecture! Things are so bad that some recent hw/os architectures have difficulty supporting dynamic linking and loading, and self modifying code, as discussed previously on these screens, and those things are the essence of modern linking technology, from the sixties onwards. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk