[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 65816 abort line on the AppleIIgs
Matthew Montchalin replied:
>On 31 Oct 2002, Michael J. Mahon wrote:
>|>I've heard conflicting information about just what happens when the
>|>Abort pin is pulled low. Is it true that it wipes out the instruction
>|>currently being executed? Someone told me that it tries to 'resume'
>|>the instruction when you finally RTI and get out of the Abort handler.
>|>Obviously a ROR <memory address> instruction, if interrupted in the
>|>middle of the rotation, is going to result in something odd after
>|>the processor resumes from the Abort.
>|
>|The intent is that it cancels the effect of the in-process instruction,
>|and it should work if asserted during the first memory-access
>|cycle of an instruction.
>
>Can you be more explicit? If ror <address> involves a read of a
>specified memory address, and then rotate some internal register
>+carry, before write-back, are you suggesting that it makes no
>difference how far into the execution we go, if the abort occurs
>prior to the write-back, the whole instruction is executed over
>again, after we get back from the Abort handler?
I said on the _first_ reference to the memory address. So the
abort would be asserted when the location was read, and before
any data was returned.
If the memory is not present, there can be no valid data. The
important part is that no internal register is updated by the
aborted instruction, so that it can be re-executed later.
>|This is consistent with it's intended use for a virtual memory
>|implementation,
>
>I was just thinking it would be more useful for implementing
>a copy-protecting mechanism to be used in conjunction with
>copy-protected software.
I don't know what you're thinking about here. NMI should do
a fine job of interrupting a program (after the conclusion of the
currently-executing instruction).
>|where it would be used to interrupt & cancel the current instruction
>|if it referred to un-mapped memory--a page fault.
>|
>|After the page has been made present by an interrupt service
>|routine,
>
>Sure, the Abort handler itself would have to save stuff to disk,
>bring something else in from disk, and then restore registers
>and RTI.
>
>|the program would be resumed at the aborted instruction
>|so that it could re-execute to completion.
>
>Hmmmmmmm.... Okay.
This is the way that all modern data page-fault handling works.
Some older machines, because of their instruction semantics,
needed to pre-check data presence before starting execution of
an instruction, because changes were made to memory prior to
a possible data page fault--for example, a page-crossing move
that could not be re-started in the middle of the move.
-michael
Check out 8-bit Apple sound that will amaze you on my
Home page: http://members.aol.com/MJMahon/