[comp.sys.apple2] MMu on the GS

rbannon@mira.acs.calpoly.edu (Roy Bannon) (01/12/91)

Instead of include the response to my previous post, I'll just summerize.

The idea put forth by the software have of this design consortium was to
use a memory mapped interface to the MMu.

On a side note, we could communicate directly by email, but I would hope
that by sending mail we could get some more people involved in this.  If
you're reading this right now and saying, what the heck is all this about
anyway, ask a question.  IMHO, this is the point of the internet is for all
of us to get together and learn something.  So don't be afriad to ask, or
even better to offer suggestions, critisizims or whatever.

Back to the point at hand (and you thought I'd forgotten :-)  )

Here's what I think a memory mapped scenario would be like.

1) System loader, which has all access, load a new process and the memory 
manager gives it an Id.  Call in proc A.  The patch to the System loader
then tells the MMu that proc A is about to be in control.

2) Proc A runs merrily along until it needs to make a system call.  It makes
the jmp (or jsr or whatever).  The machine tries to execute fetch from the
system call entry point.  At this point the MMu should abort the instruction 
cause proc a has no business at a system call entry point.  However the
abort vector isr checks the address of the bad fetch and determines that
its the tool call, so it resets the currently process to system level and
then lets the instruction restart.  At the end of the tool routine, the rtl
will not cause a page-fault, because they are at system level, so how does
the mmu know that that proc A is back in control?

3)  My second thought is about interrupts.  My thought now is when an interrupt
occurs to automattically set the level to highest.  If it went through the same
search as in 2 above, the latency befor the isr was executed would be long.
Since this would be tied to the hardware int line, brk or cop wouldn't have an 
effect.  

Anyway, I not completely convinced that a cop #XX where XX is also checked 
would be bad.  For example if we used on of the sigs that Western Design
has reserved (we know they will never use them) it would not confilct with
all the other people using cop.

So, lets here from all of you out there.

Oh yea, if this engineering curiosity is going to be a product someday, I would
like to know how many of you out there might be interested in buying such a 
thing.  It would allow some pretty neat stuff that just can't be done now.

Just send me some email.  Saying, yea, if it cost less than x.  Try to be 
reasonable about what you would pay. The good mmu chips ain't exactly cheep
themselves.  

Thanks for listening to me ramble.

Roy
rbannon@cosmos.acs.calpoly.edu

bazyar@ernie (Jawaid Bazyar) (01/12/91)

In article <278e8271.b58@petunia.CalPoly.EDU> rbannon@mira.acs.calpoly.edu (Roy Bannon) writes:

[describes how a memory-mapped scenario would execute a system call]
>then lets the instruction restart.  At the end of the tool routine, the rtl
>will not cause a page-fault, because they are at system level, so how does
>the mmu know that that proc A is back in control?

   That's pretty simply.  Instead of restarting the instruction, since we
know that it's a tool call, we make the tool call ourselves.  That way, the
tool returns to us and we can set Proc A back in control.  We can save the
registers directly to their pushed locations on the stack (done by the
exception handler) and RTI.  

>3)  My second thought is about interrupts.  My thought now is when an interrupt
>occurs to automattically set the level to highest.  If it went through the same
>search as in 2 above, the latency befor the isr was executed would be long.
>Since this would be tied to the hardware int line, brk or cop wouldn't have an 
>effect.  

   When an interrupt occurs, the '851 automatically switches to privileged 
mode.  The system would know which process was currently executing, and could
easily restore that state before the RTI instruction was executed. We have
to build a bit of logic to generate the extended instruction set codes the
'851 expects anyway, so having this logic watch for the RTI then resuming
user mode shouldn't be a problem.

>Anyway, I not completely convinced that a cop #XX where XX is also checked 
>would be bad.  For example if we used on of the sigs that Western Design
>has reserved (we know they will never use them) it would not confilct with
>all the other people using cop.

  But, as I mentioned before, a process could crash to a 'COP xx' which 
was an MMU control instruction, blowing up the system.


--
Jawaid Bazyar               | Being is Mathematics 
Senior/Computer Engineering | Love is Chemistry
bazyar@cs.uiuc.edu          | Sex is Physics
   Apple II Forever!        | Babies are engineering