Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!comp.vuw.ac.nz!windy!gpwd!gpwrdcs From: GPWRDCS@gp.govt.nz (Don Stokes, GPO) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Message-ID: <265@gp.govt.nz> Date: 2 Sep 89 00:02:54 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> Organization: Government Printing Office, Wellington, New Zealand Lines: 65 In article <205@bbxeng.UUCP>, scott@bbxeng.UUCP (Engineering) writes: > In article <5990@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: >> >>If the hardware has been designed to do "instruction continuation", >>then the user program will resume somewhere in the middle of the >>offending instruction. If the hardware has been designed for >>"instruction restart", then the program will be resumed at the start >>of the offending instruction. The user-visible result is the same in >>both cases. >> > I guess this is where I'm having a problem. What if the instruction > involved address increment/decrement modes? Restarting the instruction > might not give the exact same result unless the results of auto-inc/dec > were not placed into the affected registers until the instruction completes. > > 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? > 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: If you execute an instruction: MOVE $300, $1000 and location $1000 was not in physical memory, the OS would have to bring the page into physical memory. If the instruction continues after the pagefault completes, all is fine. If the instruction restarts, it has to access location $300 again. However, it is possible that in a tight memory situation, the act of paging in $1000 could page $300 out, and vice-versa. While an instruction continuation wouldn't mind, an instruction restart would result in an infinite loop paging $1000 in and $300 out, restarting, paging $300 in and $1000 out and restarting. While that case could probably be coded around for a simple two or three operand case (by ensuring that the last two or three pages accessed by a process remain in memory, or perhaps something cleverer?), things get somewhat messier when a block move instruction is executed, such as the VAX instruction MOVC3, which can move up to 64KB in one go, which could cross a lot of pages (of course MOVC3 is continuable on the VAX...). This wouldn't be a problem on the 680x0, as these processors (unless they've added block moves to the 68030 and/or 68040) do the grunt work of block moves in two instructions, eg: MOVE.L #scraddr, A0 MOVE.L #dstaddr, A1 MOVE.L #len, D0 loop: MOVE.B (A0)+, (A1) DJNZ D0, loop (which of course explains why the 68010 (and '012) has a two instruction cache). Don Stokes, Systems Programmer / / Domain: don@gp.govt.nz Government Printing Office, /GP/ PSImail: PSI%0530147000028::DON Wellington, New Zealand / / Bang: ...!uunet!vuwcomp!windy!gpwd!don -------------------------------------------------------------------------------- When the going gets tough, upgrade.