Aucbvax.5313 fa.works utzoo!decvax!ucbvax!works Thu Nov 26 12:15:26 1981 WorkS Digest V1 #40 >From JSol@RUTGERS Thu Nov 26 00:49:52 1981 Works Digest Wednesday, 25 Nov 1981 Volume 1 : Issue 40 Today's Topics: Demand Paging On A MC68000 Programming Environments ---------------------------------------------------------------------- Date: 24 Nov 1981 10:42 PST From: TonyWest at PARC-MAXC Subject: Re: WorkS Digest V1 #39 cc: TonyWest About demand paging on the 68000 and FEINBERG at CMU-20C's question about what makes it difficult: Yes, it is true that the 68000 has a hardware signal (BERR), which allows external logic to interrupt the processor if any of the bus cycles in an instruction cannot be completed (eg. because the page is not there). The hardware to detect references to missing pages and generate this signal is trivial. However, that is only half a solution to the demand paging problem. The other facility that is required is that, when such a fault occurs, it must be possible to stop what you're doing, load the page, *and continue again*. There are two approaches one might take: Scheme A: On a BERR, store the entire state of the processor and restore it after the missing page has been loaded so that the execution of the instruction can be resumed from whatever intermediate point it got to before it faulted (ie. don't restart the instruction from the beginning -- continue from where you left off). Scheme B: If one could only figure out which cycle of an instruction caused a fault, then, with the help of some code (which is rather similar to an instruction disassembler), one could undo the work the processor has accomplished so far in the execution of the instruction, and *then* save the starting state *before* the instruction which failed. Thus, after loading the page, the instruction can be re-run from the beginning (ie. don't continue from where you left off -- unwind the partial instruction and try it again from the beginning later). The problem with the 68000 that everyone has been talking about is that, on a Bus Error interrupt, the facilities the 68000 provides for getting your hands on the internal machine state *within* an instruction are deficient. Thus it is extremely difficult or even impossible to "trigger any special routine the user wishes when page faults or other such immediate conditions occur" and have it unwind what's going on successfully. For Scheme A, you can't restore the 68000 to a previously-saved state halfway through the instruction. For Scheme B, it is extremely complex to undo the instruction the processor has half executed so it can be re-run later. One encounters problems with things like auto-increment addressing modes, etc. I have seen it suggested that, by carefully restricting the set of instructions a code-generator is allowed to generate (eg. by avoiding things like autoincrement addressing modes), a system designer can reduce the range of possibilities of what might be going on when an instruction faults to manageable proportions. However, *intimate* knowledge is required of the way the instruction processing is performed. If you have to have demand paging, consider the following suggestions: a) Implement the two-processor scheme and have done with it. You sacrifice performance and multiprogramming during page faults. However, it's makes for a very simple system. b) Call Motorola and ask them about the timescales for availability of the following two devices I saw advertised in some of their literature (I quote verbatim): MC68010 Virtual Machine This processor is an extension of the MC68000 that readily supports advanced virtual memory techniques. MC68020 Advanced M68000 Processor This advanced 16-bit microprocessing unit will feature architectural extensions of the MC68000 such as virtual memory, co-processor support, string handling, and higher performance. c) Consider using the National Semiconductor NS16000 microprocessor, which will soon be available, and will support demand paged virtual memory from the beginning. Datasheets are available now from NS. This machine is in the same architecture and performance class as the 68000. Tony West Computer Science Laboratory Xerox Palo Alto Research Center ------------------------------ Date: 24 November 1981 17:55-EST From: Stavros M. Macrakis Subject: WorkS Digest V1 #39 / Bordelon To: ihnss!ihuxs!ihuxp!ihuxo!epb at UCB-C70 Programming environments are a major area of research. There are journals and conferences which devote a large chunk of their resources to the subject. Software Engineering Environments, ed. Horst Hunke/Huenke is the book I had in mind. But note that, e.g. Transactions on Software Engineering, IEEE, of last month had a special section on environments. These should be good starting points for a literature search. However, I am not in a position to do literature searches or bibliographies. I suggest you talk to your friendly local librarian in regard to your particular interest. When I'm ready to publish a bibliography (if ever!) I'll certainly do so.... ------------------------------ Date: 24 Nov 1981 16:55:40-PST From: ARPAVAX.hickman at Berkeley Subject: m68000 paging The person is wrong for the simple reason that it is not always possible to restart an instruction which has part way finished....I am not certain which instructions meet this class, but I believe there are some...On the z8000, for instance, the problem is easily told by: pushl @r15, rr0 Which would attempt to push r0, and r1 on the stack (r15). If the stack crosses a page boundary when it tries to push r1 (that is, push of r0 works fine, but push of r1 causes a fault) then restarting the instruction after completion of the page software would cause two copies of r0 to be put on the stack, instead of one.....There must certainly be a parrallel (?) to this on the 68000.... kipp ------------------------------ Date: 24 Nov 1981 17:12:47-PST From: decvax!yale-comix!ima!johnl at Berkeley From: John R. Levine From: The INTERACTIVE Electric Calculator Co., Cambridge MA. Subject: 68000 paging problems I am under the impression that the problem with paging on the 68000 is that you can't always restart an instruction if you get a page fault at an inconvenient place in an instruction. There's no way for the memory manager to tell the CPU to back up. That's why Apollo has two on their systems, one for regular work and the other to service page faults while the first is frozen. Believable rumors say that Motorola will have a modified 68000 out within a year that can take its own page faults. ------------------------------ Date: 24 November 1981 2049-EST (Tuesday) From: Joe.Newcomer at CMU-10A Subject: 68000 paging At least the last 68000 manual I looked at indicated that Bus Error would abort the current instruction. Alas, it is not possible in general to restart an aborted instruction, since you can't find out which byte the instruction starts on. If the solution were as simple as claimed, everyone else would be using it. The fact that so much effort is expended is because the bus error signal is NOT adequate. A little careful reading of the manual will reveal this. joe ------------------------------ End of WorkS Digest ******************* ------- ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.