Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.arch
Subject: Re: PDP-10 user I/O
Message-ID: <21820@amdcad.AMD.COM>
Date: 27 May 88 03:44:46 GMT
References: <10008@tekecs.TEK.COM>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 64

+---------------
| While we're reminiscing, the KA-10 (first PDP-10 if you don't count the
| PDP-6) had "user mode", "monitor (supervisor) mode", and "user I/O
| mode".  This last differed from user mode only in that all of those I/O
| instructions were available.  I never saw it used, either.
|   -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
+---------------

Oh, "user I/O" mode got used a LOT by folks in lab environments. Let's see,
on the Emory University Chemistry Department's KA-10, we had user-I/O mode
programs for doing data acquisition from NMR spectrometers, interfacing to
other computers, and even running a line printer. (There was no driver for
that particular printer interface, so the driver was coded into the line
printer spooler, in user mode.)  As I recall, there was even a program
that formatted DECtapes in user-mode while timesharing was going on.
(The operating system could be requseted to vector certain I/O interrupts 
to user-mode programs.)

Only disadvantage was that they had to be "trusted", since they could take
down the machine...

Coming forwards to Unix days, the v.7 "phys" call can be used for the same
thing, given memory-mapped I/O. At Fortune Systems we used to "phys" call
to implement a user-mode driver for a computer-computer channel.

User-mode I/O, in general, is a nice "fast prototyping" tool. You can write
(most of) your driver in user-mode, without taking down the machine, and
then drop it into the kernel only when it works. [No flames about the
wisdom or lack of it of doing development with live users around; you
still get the advantages of fast turnaround on a "single-user" system
if you can avoid a reboot cycle on every compiler cycle.]

If you have some sort of "pseudo-device" available (pty's can usually be
used, though not always), a rather clean development "platform" can be
erected in user-mode, with the slave end of the pseudo-device standing
in for the real device, and the "driver" controlling the master end.
A friend of mine (Mark Stein) did an entire network protocol package
this way once, with the slave ends acting as "sockets", and the "kernel"
code running as a user process holding all the master ends.

Are we far afield from "comp.arch"? Not really. I claim it is important that
new processors/systems allow (though not by default!) user-mode processes to
have selective access to I/O registers, for just this sort of "user-I/O".
For example, the Am29000 allows any mapped page to actually be in "I/O Space".

If I/O devices are allocated rather sparsely in I/O Space (by ignoring the
bottom few address bits), one could give a user process access to (say) one
I/O port but not another. (You can use a scheme similar to the "PDP-10 Monitor"
for vectoring interrupts to "wakeups": Allow a user-I/O program to plant a
short code sequence to clear the interrupt and grab time-critical data, while
the rest of the processing occurs in user mode.)

Paricularly in a PC or workstation environment, such access makes the machine
much more userul in laboratory or "real-time" environments, while also making
it easier for driver-writers.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403