johnl@esegue.segue.boston.ma.us (John R. Levine) (05/30/90)
In article <MEISSNER.90May29120158@curley.osf.org> meissner@osf.org (Michael Meissner) writes: >In article <30177@cup.portal.com> mmm@cup.portal.com (Mark Robert >Thorson) writes: > >| The 32000 has just such a mechanism for dynamically linking ROM-based code >| installed at arbitrary addresses. That is the purpose of the "software >| modules" mechanism. ... >As another article mentioned, the module mechanism is rather slow (and >when you look at the number of memory references required it's no >wonder). > >Also to use the module stuff, you have to know up front that a given >function is in the module table, since the calling sequence is >different ... You can do perfectly good module-type linking without any hardware support. The new RS/6000 has what looks like a very nice shared dynamic library scheme. A linked program or a shared library is a module. Each routine is compiled assuming that all of its called will be in the same module (which matters, because there is a shared data pointer pool for all the routines in a single module.) When you link a program, intra-module references are snapped directly, inter-module calls are redirected to glue routines generated by the linker. At load time, only the glue routines need to have addresses fixed up. To return to the previous topic of this thread, this depends critically on relative program addressing, since the code for each module is entirely read only, and the same library will show up at different addresses in different processes. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl Marlon Brando and Doris Day were born on the same day.