MIT provides MULTICS source and documentation (DPS-8 simulation)

[Chuck Guzis]

On 13 Nov 2007 at 1:21, Roy J. Tellason wrote:

> I really don't have a clue as to why you'd 
> _want_ something like a separate dedicated processor to handle I/O,  for one 
> example.  Or mass storage.  Or whatever.  And I really don't have that much 
> of a handle on how the architecture of those sorts of machines differs from 
> the micros I'm familiar with.  Even that bit of time I got to spend with the 
> Heath H11 was very alien to the rest of what I'm familiar with.

I can't imagine why anyone *wouldn't* want such a thing.  Consider 
one of the big iron systems of the 60's and 70's--the CDC 6600.  A 
CPU with 10 peripheral processors.  Within these processors, much of 
what we would call the operating system is resident.  The file 
system, job control and general I/O is handled without the 
intervention of the CPU, which is left to do what it does best--
handle user computations with a minimum of interruption.

The PPUs handle the operator display, time (task switching/time of 
day, etc.) and the basic I/O activities, including loading the 
necessary programs to do so.  PPUs can read and write CPU memory, but 
the reverse is not true--the CPU cannot interfere with the activities 
of the PPUs other than to post a request by writing to prearranged 
locations in memory.  It's very secure.

In any processor with pipelining, instruction look-ahead and caching, 
branch prediction and all of those other little gimmicks that make 
execution faster, the idea of interposing interrupts that bollix up 
all of the above is pure insanity.

For example, suppose I wanted to read a disk file.  After opening the 
file, I issue a read request to the I/O subsystem, which performs the 
necessary mapping of my logical request to a physical disk drive and 
the process is begun.  As long as I can remove data from the read 
buffer quickly enough, the processor handling my disk I/O will 
continue to read data and place it into the buffer.  

If I wanted to copy from a disk to a tape, I'd set up two requests--a 
read and a write and, as long as I could move data quickly enough, 
the operation had the potential of being continuous, with two 
processors attached to my job handling the I/O.  The amount of CPU 
time consumed is minimal.

A PPU will probably talk in turn to another specialized processor 
that's attached to a specific I/O device that further simplifies the 
interaction.  Why should a PPU do all of the work to monitor the on- 
or off-line states of a bank of disk drives when the processor in the 
controller for the drives can do it?

We see this in modern PC's with GPUs--a processor that's distinct 
from the CPU that does a better job of handling a particular task 
than the CPU.  

It just makes sense.  It's a shame we don't any modern PCs with a 
standardized peripheral processor structure, particularly given the 
cost of a microcontroller nowadays.

Cheers,
Chuck