Re: 65816 abort line on the AppleIIgs

[mjmahon@aol.com (Michael J. Mahon)]

Roy replied:

>Michael J. Mahon wrote:
>> 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.
>
>This is a bit over my head, so if I'm off, don't hesitate to correct me, 
>but, it seems to me that what you are saying is that, via a virtual 
>memory scheme, a IIgs could have much more than 16 megs of RAM 
>installed, switching banks in and out of the memory space, not too 
>dissimiliar to the old LIM EMS scheme on PCs. Have I got that right?

Virtual memory is more than bank-switched physical memory.

The usual implementation of virtual memory is to allow a processor
with a large virtual address space to operate with significantly less
physical memory, with the non-resident "memory" located on disk.
This is most useful when there are multiple processes running, so
that another active process can be running while a page fault for the
faulting task is being serviced.  In this implementation, the purpose
of virtual memory is to permit a large address space to be simulated
by a smaller physical memory.  It can only work if the "active"
pages of the program are substantially less than the "total" pages
in its address space, so that the "working set" will fit into the
available physical memory.

A virtual memory scheme can also support more total memory
space than the processor can simultaneously address.  In such
an approach, the processor's effective addresses are extended by,
for example, a process id, which is then mapped into the physical
memory through page tables.  This is a "segmented" virtual
memory, since the high order virtual address bits do not participate
in the processor's effective address calculations.

In both schemes, it is common to associate interprocess access
permissions with the page table, allowing "protected" multi-
programming and controlled interprocess communication.

It sounds like you are thinking more of the second scheme, to
permit more real memory to be used than the processor can
directly address.  In this scheme, the physical memory may be
much greater than the processor's address space (16MB), and
paging to disk may be a non-issue.

Unfortunately, no individual program could see more memory
space than what the processor can currently address, since
all existing applications operate within the processor's address
space limits.  To use more address space than this would
require application changes, akin to explicit bank switching,
since the processors effective address calculations extend
only to its native address space.  The primary value of applying
this approach to the IIgs would be to permit it to multiprogram
multiple applications.

Although this would be interesting, the relatively low performance
of the IIgs processor generally requires dedicating it to a single
task at a time, and there are no popular multiprogramming 
environments for the IIgs (GNO is pretty much a niche OS).

A virtual memory system involves some pretty specialized
hardware support (the address translation hardware), plus an
OS which handles the setup of that hardware and the page
and protection faults which it detects.  It seems unlikely that
anyone would invest the design and implementation time to
create these for the IIgs at this point.

-michael

Check out 8-bit Apple sound that will amaze you on my
Home page:  http://members.aol.com/MJMahon/