ron@BRL.ARPA (Ron Natalie) (10/24/85)
An #ifdef VAX would be superfluous here. The loader is one of the more machine dependant parts of any system. Not only does it depend on the format of your relocatable files, but it depends on both the hardware instruction set and the memorym management system being employed. Even who loaders for the same microprocessor would therefore be substatnially different if they had dissimilar memory schemes. -Ron
henry@utzoo.UUCP (Henry Spencer) (10/31/85)
> An #ifdef VAX would be superfluous here. The loader is one of the more > machine dependant parts of any system. Not only does it depend on the > format of your relocatable files, but it depends on both the hardware > instruction set and the memorym management system being employed. Even > who loaders for the same microprocessor would therefore be substatnially > different if they had dissimilar memory schemes. Actually, by using a reasonably powerful and flexible object-module format, like the IEEE P695 proposal, it is quite possible to build a machine- independent loader. (It's been done, for a version of P695.) The loader doesn't have to know that 010537 means "mov r5, $#something", all it has to know is how it should adjust the number for relocation and linking. The variety of approaches to that is non-trivial, but much smaller. Even when one must cope with existing object-file formats which lack the needed flexibility, it is still silly to introduce gratuitous unportability into code which can be *mostly* machine-independent. (Reference: a draft of P695 was published in the August 1983 issue of IEEE Micro. See that for further information.) (Oh yes, to head off anyone suggesting that the /usr/group / IEEE Unix standards effort should have had P695 brought to its attention: I did. The consensus was that investment in existing object-module formats is too heavy to expect changes. I still think that much could be accomplished in this direction if an influential standards body gave new Unix ports a firm push that way. Easier said than done, alas.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jans@mako.UUCP (Jan Steinman) (11/03/85)
In article <6103@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> An #ifdef VAX would be superfluous here. The loader is one of the more >> machine dependant parts of any system. Not only does it depend on the >> format of your relocatable files, but it depends on both the hardware >> instruction set and the memorym management system being employed... > >Actually, by using a reasonably powerful and flexible object-module format, >like the IEEE P695 proposal, it is quite possible to build a machine- >independent loader... I don't know that we use anything similar to P695, but the UTek (cleaned-up 4.2) loader accepts either VAX or NS32000 load modules without complaint. We also have a nice, WORKING distributed file system. The combination presents some interesting problems. Due to storage space problems, I usually have my source code on a VAX, and ``cd'' to it over the DFS to ``make'' on my NS32000 workstation. If, by chance, some of the modules were compiled on the VAX, (sometimes it's hard to remember what machine you're on) the NS32000 ``ld'' merrily and without question links them together with NS32000 code. If there is enough NS32000 code to do something useful (at least main()) the resultant ``illegal instruction -- core dumped'' message can be quite puzzling when the poor NS32000 sees it's first VAX instruction! -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 61-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
johnl@ima.UUCP (11/04/85)
> An #ifdef VAX would be superfluous here. The loader is one of the more > machine dependant parts of any system. Assuming you mean the linker, that's not true at all. At Interactive Systems, we came up with a common object format for all of the byte- addressable machines we were working on and a single linker that could link for any of them. PC/IX and VM/IX really use the same linker, and (except for bugs and perhaps old versions) either linker can link code for either machine. Also, there is a single version of nm, strip, and so forth, which makes life much easier. It turned out to be easier than I would have thought, since there seem only to be about a dozen different kind of link-time fixups that any of the machines we know about need. A moderate number of flags, usually passed in from "cc", proved adequate to deal with the various forms of split I/D, segmented addressing and so forth. More work would be needed if we were going to move to, say, shared libraries or dynamic linking, but we thought of reasonable ways to deal with that. There is a paper on the common object format and its tools in one of the Usenix proceedings from about two years ago. John Levine, ima!johnl PS: I figured this would be really great in a system with, say, a 68000 and a 286, where each object module would automatically be run on the processor it was linked for.
bobd@zaphod.UUCP (Bob Dalgleish) (11/13/85)
In article <6103@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> An #ifdef VAX would be superfluous here. The loader is one of the more >> machine dependant parts of any system. Not only does it depend on the >> format of your relocatable files, but it depends on both the hardware >> instruction set and the memorym management system being employed. > >Actually, by using a reasonably powerful and flexible object-module format, >like the IEEE P695 proposal, it is quite possible to build a machine- >independent loader. > >(Oh yes, to head off anyone suggesting that the /usr/group / IEEE Unix >standards effort should have had P695 brought to its attention: I did. > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry We have had some experience with a P695 (MUFOM) linker: 1) It is machine independent. The same loader is used for Z8000, Z80, and Z800 code. 2) It is very inefficient, and not particularly the programs fault. Point (1) is very useful to us, since we deal with a non-trivial number of processors. Point (2) arises because the standard itself is inefficient. For example, to produce a namelist (i.e., 'nm(1)'), a program has to read and examine the *entire file* - 40% of the file can be skipped over, 3 to 100 bytes at a time. The 'size(1)' command has the same problem, since the size of the file is the sum of the load blocks that make up the file. These examples of course could be fixed up, of course, by conventionally putting this information near the front of the file in comments. *However*, it is only a convention and will not work since it is not standard. For those who are preparing to hit the 'F'lame key about efficiency: Imagine waiting 40 minutes on a VAX11-780 for a load to happen when it could have been done in under 5 minutes using a conventional architecture loader. -- [Forgive me, Father, for I have signed ...] Bob Dalgleish ...!alberta!sask!zaphod!bobd ihnp4! (My company has disclaimed any knowledge of me and whatever I might say)
henry@utzoo.UUCP (Henry Spencer) (11/21/85)
> We have had some experience with a P695 (MUFOM) linker: > ... > 2) It is very inefficient, and not particularly the programs fault. > ... Point (2) arises because the standard itself is > inefficient. For example, to produce a namelist (i.e., 'nm(1)'), a > program has to read and examine the *entire file* - 40% of the file can > be skipped over, 3 to 100 bytes at a time... > These examples of course could be fixed up, of course, by conventionally > putting this information near the front of the file in comments. > *However*, it is only a convention and will not work since it is not > standard. That doesn't follow. A P695 linker ought to be able to handle the full standard, but that does *not* imply that it must be equally (in)efficient for all possible inputs. There is nothing wrong with saying "if you want it to run fast, observe the following conventions and restrictions...". (I agree that it would be nice if said conventions were part of the standard, which would greatly increase the chances that randomly-chosen P695 software would observe them, but it's not vital.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry