🚀 go-pugleaf

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.