Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!pp!hugi!ken
From: ken@hugi.ACA.MCC.COM (Ken Zink)
Newsgroups: comp.arch
Subject: Re: DMA on RISC-based systems
Summary: "Intellegent I/O" processors on the 6600 also performed other functions
Message-ID: <247@hugi.ACA.MCC.COM>
Date: 9 Jun 89 22:17:00 GMT
References: <46500067@uxe.cso.uiuc.edu> <28200325@mcdurb> <2819@scolex.sco.COM> <108123@sun.Eng.Sun.COM>
Organization: MCC, Austin, TX
Lines: 41


Without getting totally mired in ancient history, I think it is germane
to the discussion to point out that the "I/O processors" (called "peripheral
processors" by CDC) had sufficient intellegence to do more than I/O.
In fact, for the first ten years or so of the 6000 architecture (6600, 6400,
Cyber 70, Cyber 170, lower), the ENTIRE operating system resided in the
domain of the "lowly" PP's.  It seems that very few operating system
functions really require floating point capability or 60 bits of significance.

One of the PP's was dedicated to "system monitor" functions and was
staticly allocated; one other PP was staticly allocated and assigned to
driving the system console (dual 15 inch CRT's).  The rest of the PP's
were dynamically assigned, by PP Monitor, to perform I/O or some OS
function as necessary. [Note: On the 20 PP systems, any PP could access
any I/O channel or else it caused too many problems in the OS to determine
which available PP could handle a given I/O request.]

Since the early systems were limited to 131K words of central (60 bit)
memory, having the OS reside in the PP world preserved the critical
memory resource for user job space.  As larger memory configurations
became available, a few of the most often used OS functions were migrated
to CP code - for performance.

The 7000 architecture (7600, Cyber 170/Model 176) with the PP's hard-wired
to external channels and to central memory buffers dictated that the OS
be CPU (60 bit) based.

In summary, there is a spectrum of system architectures with "intellegent"
I/O ranging, perhaps, from the dumbest of DMA-like to clusters of identical
processors, equally capable of performing an I/O function or executing
user provided code.  An optimal architecture would trade-off all of the
options in that spectrum against the available-technologies, cost-to-
manufacture, price-in-the-market, performance-in-the-desired-target-
application(s) and market-acceptability variables to determine which
of the options is "optimal."

In short, as we know, there is no single, best architecture.

Ken Zink            zink@mcc.com
MCC
Austin, TX