kwan@smeagol.UUCP (Richard Kwan) (01/09/86)
In <6234@utzoo.UUCP>, Henry Spencer wrote: >... For lack of >anything better, net.unix or net.micro would be the obvious places for >this one. ... >...Over and over again, groups have >been created as the result of popular enthusiasm, only to fizzle and >die because nobody ever submitted anything to them after the first week. This article really belongs in net.os/mod.os. At the risk of being flamed out of existence for impatience, I thought I would show a little interest in the proposed group. (...Halon system enabled... :-} ) ----- I assume that a large number of the UNIX utilities use a lot of common code, e.g., strcmp(), strcpy(), bcopy(), etc., etc. ...that is, many of the things that can be found in 'libc.a'. Certainly, my own code is riddled with such things. This means that as executable files are created, they include a considerable amount of code which has been duplicated elsewhere, i.e., in other executable files. This is certainly the case for PDP-11 UNIX systems, probably VAX systems, many 68000 systems, etc. It means that disk space has to be sufficiently large to hold all the duplicated as well as unique code. This is probably a stumbling block in getting a well-endowed UNIX system onto a PC, whether IBM PC or anything else. (The people at Interactive Systems in Santa Monica, CA, probably have a better insight into this.) My Smalltalk friends have got me thinking... Suppose (1) executable files are unlinked executables and the ".o" files that they refer to, instead of fully linked executables, and that (2) upon a trap to an unknown routine(), the system resolves the address or loads in the appropriate ".o" and then resolves. The following positive results should occur: 1. Less disk space should be required for executables. 2. Many of the ".o" files needed for address resolution should already be in main memory. 3. The amount of paging and swapping for a given work load should go down or disappear. 4. Option-driven code (e.g., code selected by various "-" options in UNIX commands) which is rarely invoked will rarely take up space in main memory. 5. The amount of main memory required to support a given mix of application code should go down. (But see item 2 below.) The following negative results should also occur: 1. Additional memory accesses would be needed to reference routinetinaddresses from a table rather than the immediate instruction stream. 2. Kernal code and data space would be required to support resolution. (There are probably hardware solutions to item 1, but I haven't heard of any being implemented.) As for getting it implemented, memory management of position independent code which is shared by different process address spaces would be a major kernal rewrite, akin to adding demand paging to UNIX/32V. Furthermore, a new "C" compiler and linker would be required. People and articles seem to indicate that the following systems are implemented this way: Multics, AT&T 7300, National's GENIX, Apollo DOMAIN. (Any of this list incorrect? Smalltalk is similar, but only uses a single address space.) Slowly, I am beginning to favor this approach for the following reasons: 1. CPU speeds are increasing; disk seeks do not seem to have kept pace. 2. As applications get more sophisticated, they seem to require more and more common code. 3. Paging is now a common feature of small systems (well, super- micros, anyway). Thus, there is a mechanism for caching small routines. (I don't think you could do this on a PDP-11.) Alas, this is not a standard feature of UNIX; nor would I expect it to become one (...not as long as people keep their sights on IBM PCs). Nor do I know how well the above named systems implement this type of strategy. You operating system architects and aficionados out there, your comments are appreciated. (And when net.os or mod.os gets started, please direct your responses there.) Rick Kwan JPL ----- (I am keeping the asbestos suit handy :-} )