mmm@cup.portal.com (Mark Robert Thorson) (05/25/90)
> > Do you really care if you can move code in memory without > >re-relocating it? Obviously there is a possibility of using a small > >offset for jumps to same a few bytes, but it doesn't make the compiler > >harder to write (does it?) that I can see. > > > PC relative is nice for embedded systems. It lets you plug code ROMs > in at arbitrary addresses without having to reprogram them. > > PC relative for code, obviously (it's also useful for normal systems). > Embedded systems also can use PC relative for access to constant data, > although PC relative access to variables is less useful. > -- > Andy Glew, aglew@uiuc.edu 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. The same mechanism could be used to get some of the benefits of position-independent code, for example if you wanted to load device drivers on-the-fly into arbitrary positions in free memory (the way the old RT-11 operating system for the PDP-11 worked), but the overhead for setup when the driver is loaded would be higher. disclaimer: I suppose it's a little late to mention this, but I worked in National's Microprocessor Marketing Group supporting the 16000 in 1980 :-) I left at the end of 1980, shortly after first silicon arrived (nearly a year behind schedule). I didn't follow the situation after that, so I don't know when customers first saw silicon, or when the bugs went away.
meissner@osf.org (Michael Meissner) (05/29/90)
In article <30177@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: | > > Do you really care if you can move code in memory without | > >re-relocating it? Obviously there is a possibility of using a small | > >offset for jumps to same a few bytes, but it doesn't make the compiler | > >harder to write (does it?) that I can see. | > | > | > PC relative is nice for embedded systems. It lets you plug code ROMs | > in at arbitrary addresses without having to reprogram them. | > | > PC relative for code, obviously (it's also useful for normal systems). | > Embedded systems also can use PC relative for access to constant data, | > although PC relative access to variables is less useful. | > -- | > Andy Glew, aglew@uiuc.edu | | 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. The same mechanism could be used to get some of the | benefits of position-independent code, for example if you wanted to load | device drivers on-the-fly into arbitrary positions in free memory (the | way the old RT-11 operating system for the PDP-11 worked), but the overhead | for setup when the driver is loaded would be higher. 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 (different call/return instructions, and the arguments are at different offsets on the stack frames). The module table is limited to be the first 64K of memory, which means you can have 4K functions (64K / (4 * 4)), or 16K data references. The limit on functions is rather low when dealing with todays windowed megalibraries. Finally, neither GCC nor the Greenhills compiler generate the module calls by default (and the previously mentioned article also speculated that National eventually removed modules from their code). The module table is a nice idea in theory, but terrible in practice. | disclaimer: I suppose it's a little late to mention this, but I worked | in National's Microprocessor Marketing Group supporting the 16000 in 1980 :-) | I left at the end of 1980, shortly after first silicon arrived (nearly a | year behind schedule). I didn't follow the situation after that, so I don't | know when customers first saw silicon, or when the bugs went away. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so