🚀 go-pugleaf

In article <679@opal.tubopal.UUCP> alderaan@tubopal.UUCP (Thomas Cervera) writes:
|In article <1070@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
|=[]
|=                          Whereas the 68010, 68020 etc. store much
|=information on the stack at a BUSERR (29 words if I'm correct), the
|=68000 only stores 7 words, which is not sufficient to resume each type
|=of instruction.  For instance:
|=
|=    movem.l   (a3),a2-a5
|=
|=Since this instruction modifies the contents of a3, it cannot be resumed
|=when a bus error occurs after a3 has been modified (and the instruction
|=has not yet completed).
|
|  I'm not that familiar with the 68000's hardware and pin configuration.
|But isn't there a pin telling the non-existent MMU 'shut up, I'm working on
|an instruction right now !' ?
|  Sure, the MMU must be able to hold it's BUSERR signal back until the CPU
|drops this line and tries to fetch the next instruction.
|  If this is possible, error recovery on BUSERR should not be a problem.

I think you missed my point. The data pointed to by a3 could lay near a
page boundary. For instance a2-a3 can still be fetched, but a4 must be
read in from a not (yet) existing address (which causes a BUSERR). a3
has been modified, so you cannot repeat the instruction (you have to
know the original contents of a3 to do that).

You could hold back the BUSERR signal, but I don't know what good that
will do to you. You still have to execute the instruction. Execution of
the instruction causes the BUSERR, which kicks the BUSERR exception
handler to page in the new memory, after which the instruction can be
restarted at the point it was interrupted (reading a value for a4 in
the sample case).  68010's and 68020's etc. store enough intermediate
data to resume an instruction this way, 68000's do not. The whole point
is that the BUSERR exception is just the means to trigger the paging
event.

   Leo.