wpd@athena.mit.edu (William P Doyle) (06/29/87)
<insert cutsey line-eater joke here>
I was recently speaking with a gentleman who informed me that it was
possible to implement virtual memory with a 68000 (not a 68010, 20,
etc...), providing, of course, that one has an appropriate MMU. I was
under the impression that, because the 68000 could not restart
instructions, VM wasn't possible. His argument went something like,
"You know that you will never page fault while in the supervisor mode,
so you just insert probes in the user mode." Now, I could have
misunderstood him, or perhaps, mis-remembered what he said, but I just
don't understand. Does this mean that, before each instruction, there
must be a TST instruction to see if the page is in memory? I could
beleive that, the buserr handler would then just check to see if this
"probe" instruction was at fault and be able to restart the program,
(after loading the appropriate page into memory), at the following
instruction. These seems a bit inefficient though :-). Could someone
please enlighten me?
______________________________________________
| |
| Patrick Doyle wpd@ATHENA.MIT.EDU |
| ...{decvax,ihnp4}!mit-eddie!mit-athena!wpd |
|____________________________________________|gnu@hoptoad.uucp (John Gilmore) (07/02/87)
wpd@athena.mit.edu (William P Doyle) wrote: > ...because the 68000 could not restart > instructions, VM wasn't possible. His argument went something like, > "You know that you will never page fault while in the supervisor mode, > so you just insert probes in the user mode." Early 68000 Unix systems worked this way; they did not do virtual memory, though; they swapped, like V7 Unix and most System V's until recently. (The most serious constraint this gives is that you can't run programs bigger than your physical memory.) The "probe" method was used to dynamically allocate the stack. Each procedure prologue had a "tst sp@(-128)" instruction, or something similar. If the stack was close to its end, this would get a bus error. Enough was known about the behaviour of the 68000 that restarting that simple instruction was possible; e.g. we knew how far off the PC was from where it should be. If we didn't do the stack probe, some random instruction that referenced the stack might get a bus error, and not enough information would be there to restart it. On the Macintosh, I understand that Apple did something similar for procedure calls to non-resident libraries; they figured out what the chip would do with an instruction like "jsr a0@" to a bad address, and if it happens, they fix it up. Apollo used to do virtual memory using a pair of 68000's; when the first one took a bus error for a missing page, it would be frozen in mid-cycle, and the second 68000 would take over, fetch the page, and resume the first. This worked, but had the serious drawback that you can't run some other process while waiting for the disk to spin. 68010's are now so cheap that there is no excuse for using a 68000 for a system with an MMU. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Alt.all: the alternative radio of the Usenet. Contributions welcome - post 'em
lsr@apple.UUCP (Larry Rosenstein) (07/02/87)
In article <2351@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > >On the Macintosh, I understand that Apple did something similar for >procedure calls to non-resident libraries; they figured out what the >chip would do with an instruction like "jsr a0@" to a bad address, and >if it happens, they fix it up. Half true. This was done on the Lisa, not the Macintosh. Procedure calls and returns only involved a limited number of instructions, and the O/S knew how to restart them. This gave us the ability to dynamically load and unload code segments. Since references to data segments could be done with a variety of instructions, the Lisa O/S could not dynamically load data segments. (The Lisa also used the stack expansion technique described earlier.) The Macintosh dynamically loads segments using a totally different scheme, and cannot (easily) unload a segment is being used somewhere on the call stack. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com