MIT provides MULTICS source and documentation (DPS-8 simulation)
cclist at sydex.com
Tue Nov 13 12:30:10 CST 2007
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.
More information about the cctech