Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!mips!daver!bungi.com!news
From: culberts@hplwbc.hpl.hp.com (Bruce Culbertson)
Newsgroups: comp.sys.nsc.32k
Subject: Re:  MMU and disk
Message-ID: <9011091811.AA10761@hplwbc.hpl.hp.com>
Date: 9 Nov 90 18:11:59 GMT
Sender: news@daver.bungi.com
Lines: 70
Approved: news@daver.bungi.com

> Not having anything better to do, I decided to change the debugger so
> that memory is mapped thru the MMU. I mapped the I/O regions with the
> CI (cache inhibit) bit turned on.
> ...
> Do any of you more experienced 32532-ers have any ideas? Is anyone else
> using the MMU?

Sometimes when you most need the debugger, you are trying to debug
a user program which goes so crazy that it disables the debugger.
I tried to minimize the number of ways this could happen so I made
the debugger operate in unmapped mode and without interrupts.  This
may be futile, of course, since the user code can still bomb the
debugger by writing over its stack.  I am just trying to explain
why I did things the way I did -- I am not trying to discourage
Gary's experimentation.

Is anyone else using the MMU?  Yes.  Minix runs user code in mapped
spaces.  It runs its own code unmapped.

The debugger is aware of the MMU in some very limited ways.  When
returning from user code, the monitor disassembles the instruction
which the user's pc points to.  If the user pc is mapped, as indicated
by the psr and mcr, then the address of the disassembled instruction
is followed by a V.  For example, Minix users who use my bpt program will
see something like:

	58V	bpt	(breakpoint exception)
	Command (type ? for help):

This indicates that the user code was exitted due to a breakpoint
exception, and that the next user instruction is bpt and is located at
0x58 in the user's virtual space.  Where is 58V in physical memory?
The monitor's expression syntax includes a function for converting
virtual addresses to physical addresses.  Here are some examples.

v(48123) returns 0x48123 if 1) the psr indicates supervisor mode and
mcr indicates that supervisor is unmapped or 2) the psr indicates
user mode and mcr indicates that user is unmapped.

v(48123) returns 0x34123 if the psr indicates supervisor mode,
mcr indicates that supervisor is mapped, and ptb0 points to a
page table which maps the virtual page at 0x48000 to a physical
page at 0x34000.

v(48123) returns 0x34123 if the psr indicates user mode,
mcr indicates that user is mapped, and ptb1 points to a
page table which maps the virtual page at 0x48000 to a physical
page at 0x34000.

v(48123, 4000) returns 0x34123 if 4000 points to a
page table which maps the virtual page at 0x48000 to a physical
page at 0x34000.

I do not have any good ideas regarding the disk problems Gary is
having.  Most I/O addresses cause a 32532 signal (called /ioh?)
to be asserted.  This prevents caching, regardless of the ci bit
in the pte.  The data ports for the SCSI controllers, however,
do not assert /ioh.  This is to circumvent a '532 bug -- if /ioh
is asserted, the '532 seems to fetch both data and instructions
from memory.  This doubles the number of memory cycles to read/
write a disk block, which noticably affects disk performance.
I know this does not answer Gary's question -- I am just trying
to describe some of the complications.

By the way, I think I used "user" in three different ways --
monitor code versus non-monitor code, 32532 supervisor versus
user mode, and Minix OS code versus application code.  Hope
you can figure out what I meant.

Bruce Culbertson