tp@ndm20 (05/21/86)
>>I work with very large programs that are under constant development. Much >>time is spent waiting for them to be relinked after a modification to a >>small number of modules. > >This is handled pretty well in VAX/VMS with linkable images. By >maintaining a table of entry points at a constant location in the >linkable image (typically at the beginning), programs which call >routines in that image don't need to be relinked when that image (or a >routine in it) is updated. That only works if you have a stable library to make an image of. If you are just doing development and want to be able to make a change to any module, VMS doesn't do it any better than any other system. I read somewhere that the NS32000 cpu has hardware support for this by calling modules through a jump table, but you still need software support so you can modify the jump table and link in just the new routines (i.e. change the jump table pointer for the routine to point to the new version, and then satisfy only the references in the new routine, and you will have a newly linked version. You would only have to do a link from scratch when the executable got to big for your (or your loader!)'s taste.) Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: {seismo!c1east | cbosgd!sun | ihnp4}!convex!infoswx!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA
aglew@ccvaxa.UUCP (05/22/86)
~> Support for linking... Terry Poot mentions the NS32000's module tables. Does anybody know of any applications that actually USE these modes? It seems to me that linking is very much like the problem of how you make sure pointers to objects in LISP remain valid after objects have been moved around by a garbage collection. Either you update all the pointers, ie. have a relocation list of all calls, and patch in the actual address when linking, or you use double indirection - jump tables, and the like. Double indirection is clean, except that it requires doing two fetches to get the actual address of the module being called - unless you are willing to spend some time making caches that do double indirections as fast as single... Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms
dricej@drilex.UUCP (Craig Jackson) (05/24/86)
In article <109@c3pe.UUCP> charles@c3pe.UUCP writes: >In article <1992@mit-eddie.MIT.EDU>, jbs@mit-eddie.MIT.EDU (Jeff Siegal) writes: >> In article <219@zeus.UUCP> jayb@zeus.UUCP (Jay Beck) writes: >> >What I would like to see happen is for computer architects (and us software >> >engineers too) to build systems that eliminate the linkage step when we are >> >developing and running these large programs. >> > >In the Multics system (which, granted, requires some pretty unique hardware), >external references are set to trap the processor when invoked, instead of >linking in the routines. A pointer to the desired symbol is left lying around, >and that's about all the compile-time effort for external reference >resolution. > Burroughs Large Systems (B6700, B7700, et al, and A-series) have been doing dynamic linking for many years. Originally it was only done for system library subroutines; there was a single 'intrinsic' library that was linked to at the first reference for each subroutine at run time. Today, Burroughs has gone wholeheartedly towards run-time binding to library subroutines. In fact, they wanted to eliminate the static binder completely, but the user community made them keep it. (It had always been buggy, and Burroughs didn't want to fix it.) (Weird formatting brought to you by 2.10.3 inews) Craig Jackson UUCP: {harvard,linus}!axiom!drilex!dricej BIX: cjackson -- Craig Jackson UUCP: {harvard,linus}!axiom!drilex!dricej BIX: cjackson
henry@utzoo.UUCP (Henry Spencer) (05/26/86)
> Terry Poot mentions the NS32000's module tables. Does anybody know of any > applications that actually USE these modes? They're unpopular because they're slow. Even ignoring the linking operation itself, accessing stuff through the module table simply isn't quick. It *is* a bit more compact, but that isn't quite such a concern these days. A further complication is that the module table is constrained to be in the first 64KB of the address space. This means that the issue has to get thought about early on, so that memory layout will permit it. In particular, the resulting layout isn't compatible with the old PDP-11-derived layout that is popular for Unix ports. The result is that people tend to decide that it's more hassle than it's worth. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry