🚀 go-pugleaf

In article <18766@sequent.UUCP> jjb@sequent.UUCP (Jeff Berkowitz) writes:
>In article <1449@mdbs.UUCP> wsmith@mdbs.UUCP (Bill Smith) writes:
>>What will happen when [a long] instruction crosses a page boundary and
>>a page fault occurs? 

Actually, in the case of the VAX, a two-byte instruction can cross a
page boundary.

There are two? solutions.  One would be to "back out" of an instruction,
that is, pretend it never started, before taking the trap.  This would
require saving the PC of the opcode, and un-autoinc/dec'ing of registers
that had been done along the way.  The second method is to actually save
and restore as much raw inner hardware state as is necessary to resume
the instruction upon return.  Advantages of (1) include less hardware
(don't need read/write paths to so much hardware state, and the sequencing
logic to handle the process).  (2) would allow the instruction to be
more "continuable" in the sense that once a page is used in the parsing
of an instruction, it can be paged out and not needed again after the
page fault causing the problem has been brought in.

>Page boundries seem to be a fertile source of CPU hardware bugs, however.

This is one of the many reasons RAM is desirable for microcode.  The
supplier can fix bugs by sending out patches.

>I imagine the page-fault-time (hardware) state save operations on heavily
>pipelined CISCs like the 486 and 68040 must be extraordinarily complex.
>Perhaps a designer out there can comment about this.  Current generation
>RISCs achieve comparable (or better) performance with much lower
>complexity in this area, yes?  Complexity always ends up costing money ...

A lot of this complexity is common to both RISC's and CISC's,
howwever.  This would be the class of problem of instruction N gets a
page fault doing its memory operation, while N+1 and N-1 etc are still
in various stages of execution.  One way to keep this complexity to a
minimum is to design the pipeline such that exeptions can only happen
at fixed points, that when an exceptions happen all older instructions
complete, and that any newer instructions (started after the
instruction causing the exception) are aborted.  Then, state can be
saved, and execution eventually resumed, in the most straightforward
way.  

Nah - just spill all hardware state on the stack.
-Stan