Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!think!snorkelwacker!apple!portal!cup.portal.com!mmm From: mmm@cup.portal.com (Mark Robert Thorson) Newsgroups: comp.arch Subject: Re: 32016 PC-relative (was: bubble mem) Message-ID: <30177@cup.portal.com> Date: 24 May 90 18:01:26 GMT References: <1990May18.170721.12758@utzoo.uucp> <107340001@hpcuhc.HP.COM><2252@crdos1.crd.ge.COM> <2257@crdos1.crd.ge.COM> Organization: The Portal System (TM) Lines: 28 > > 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.