Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!hp4nl!philapd!ssp1!roelof From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Summary: Changing viewpoints (long) Message-ID: <241@ssp1.idca.tds.philips.nl> Date: 4 Sep 89 16:53:35 GMT References: <1989Aug24.215104.156@mentor.com> <231@ssp1.idca.tds.philips.nl> <2345@oakhill.UUCP> <204@bbxeng.UUCP> <5990@pt.cs.cmu.edu> <205@bbxeng.UUCP> <265@gp.govt.nz> Organization: Philips Telecommunication and Data Systems, The Netherlands Lines: 109 In article <265@gp.govt.nz> GPWRDCS@gp.govt.nz (Don Stokes, GPO) writes: >In article <205@bbxeng.UUCP>, scott@bbxeng.UUCP (Engineering) writes: >> >> I remember reading some literature when the 68010 came out explaining the >> wonderful benefits of instruction continuation and why instruction restart >> did not always solve the problem. (I don't remember *where* I read this.) >> Now I'm hearing that it doesn't really matter. Instruction restart makes >> a lot more sense to me as long as the side effects of the instruction are >> not not interruptable. Is this the case with the 68040? To begin with the last point first, its my understanding that due to data prefetching and the restart exception model the same location can sometimes be accessed twice (which can be, uhmmm, unpleasant for memory-mapped i/o) which is why motorola no longer claims virtual machine support for the 68040. My understanding could be flawed though... But maybe we can second-guess motorola. How about the following scenario: In order to improve perfomance, motorola decides to pipeline heavily, heavy pipeline means a lot of data prefetching. Now with all that prefetched data we suddenly run into an exception...problems. Best thing is throw it all away and start anew. Now the whole point of instruction continuation was to know which locations were already accessed. Since this could no longer be supported might as well go over to the simpler instruction restart. So the real trade-off was performance vs virtual machine support. Could this be the story behind the instruction continuation discontinuation? Stay tuned :-) As for the first point: The 68010 programmers reference manual motivates instruction continuation as follows (1.4.1 Virtual Memory p.8): "The MC68010 uses instruction continuation rather than instruction restart to support virtual memory. With instruction restart, the processor must remember the exact state of the system before each instruction is started in order to restore that state if a page is fault occurs during its execution. Then, after the page fault has been repaired, the entire instruction that caused the fault is reexecuted. With instruction continuation, when a page fault occurs the processor stores its internal state and then after the page fault is repaired, restores that internal state and continues execution of the instruction. In order for the mc68010 to utilize instruction continuation, it stores its internal state on the supervisor stack when a bus cycle is terminated with a bus error signal...... Instruction continuation has the additional advantage of allowing hardware support for virtual i/o devices. Since virtual registers may be simulated in the memory map, an access to such a register will cause a fault and the function of the register can be emulated by software." Now, especially in the light of preceding discussion in this group, it is not clear to me how the first paragraph above motivates instruction continuation above restart. Apparently the motorola folks seem to agree since in the 68020 Users Manual we read the following (1.3.1 Virtual memory p.1-7): "The MC68020 uses instruction continuation to support virtual memory. In order for the mc68020 to use instruction continuation, it stores its internal state... ...Instruction continuation is crucial to the support of virtual i/o devices in memory-mapped input/output systems. Since virtual registers may be simulated in the memory map, an access to such a register will cause a fault and the function of the register can be emulated in software." Note the two differences: first, no more mention of instruction restart and second, what was first an "additional advantage" has now become "crucial". For the 68030 we see again a changed viewpoint: In the 68030 users manual we read (in 1.6.1 Virtual Memory p.1-11): "The mc68030 uses instruction continuation to support virtual memory..." and in 1.6.2 Virtual Machine: "Instruction continuation is used to support i/o devices in memory-mapped input/output systems. Control and data registers for the virtual device are simulated in the memory map. An access to a virtual register causes a fault and the function of the register is emualated by software." Note the differences: first, instruction continuation is no longer "crucial" to support memory mapped i/o devices and second, the motorola folks have finally figured out that memory-mapping i/o devices is a virtual machine concept and not a virtual memory concept. And finally of course (what started this whole thread): the 68040's non-support of instruction continuation. > >I think I saw something similar in the depths of my MC68020 User's Guide >(I love the way Motorola call the technical docs for a processor a >"User's Guide"). Might dig it out sometime, but I think the gist of it >was as follows: > [ Example follows] You might want to dig it out sometime since I (for one) couldn't find it. -- wiskunde: Dutch for mathematics. Literally: Knowledge of certainty wis: certainty kunde: Knowledge Roelof Vuurboom SSP/V3 Philips TDS Apeldoorn, The Netherlands +31 55 432226 domain: roelof@idca.tds.philips.nl uucp: ...!mcvax!philapd!roelof