🚀 go-pugleaf

In article <5932@pt.cs.cmu.edu> butcher@g.gp.cs.cmu.edu (Lawrence Butcher) writes:
>My new question.  Is fast I/O all that micros need to bury mainframes?  Or
>is user level I/O needed?  

In article <?????> Sean Fagan writes:
>CDC Cyber's don't; they do have protection (in both senses that I got from
>the above paragraph).  Like other Seymour Cray machines, it doesn't have
>virtual memory; instead, you have a "base address" and a "limit register"

Being an ex-CDC'er, I have to clear up a glaring omission: the above
applies to the old Cyber 170's - the newer 180's do have virtual
memory - quite Multics-like. (Except much bigger segments. "For
God's sake," said the Multics folks, "make the segments as big as
you can!")  Having seen other postings of Sean's, I'm sure he's
aware of this - just a slip.  Don't let it happen again ;-).

As for user-level I/O, do you (LB) mean for controlling special-purpose
devices (not common in the mainframe world) or for dealing with weird
and wonderful data structures out on disk?  For the latter, the 180
architecture, along with the NOS/VE OS, provides what I think is the
ultimate(*) in user-level i/o: none!  What I really mean is: implicit i/o
via memory mapped files.  Simply associate a file(s) with a data
structure(s) in the virtual address space of your software, and 
access it anyway you like.  Actual physical i/o occurs simply as
part of normal paging.  No fuss, no muss.
(*) but then, I'm not up on what people generally mean by user-level
i/o.

This works really well with large memories (like where your database
starts to look memory-resident). Especially if you can safely leave
modified data in memory without writing it to disk until the pages
simply get aged out.  I believe this is one place where current micros,
risc or cisc, fall down on the job: it's difficult, if not impossible,
to recover central memory when the system crashes.  (I'm sure people
who know otherwise will enlighten me as to how easily it can be done!)
The segments and rings of 180 provide firewalling - errors, be they
hardware faults, user, application, or os bugs, are well identified
and well contained.  Only if something goes wrong in the innermost
ring, in which the system spends a minimum of time, do things get
tricky - and that can usually be handled with a consistency check.
This sort of recovery capability is crucial for database systems -
one of the primary domains of mainframes.

This is starting to look more like an advertisement for fault-tolerance
rather than efficient user-level i/o.  Just another aspect of the
world of difference between micros and mainframes.  Lest this also
look like an advertisement for Cyber 180s, let me say that other
mainframes likely have similar capabilities, and probably some micro-
based systems can do some of it (like memory mapped files), but like
I said, there's still a world of difference between micros and mainframes.

>Fast I/O is necessary, yes, for micros to "bury mainframes"; however, you
>also need a way to *use* that, which, hardware-wise, will require better
>memory subsystems (so that you can do I/O to at least one memory location and
>still run code at full speed).  Also, of course, you need an OS that will
>take advantage of it, etc.

>Sean Eric Fagan  |    "[Space] is not for the timid."

Hear, hear.  And effective cache coherency - no mean feat in this 
sort of system.

----------------
Dave Christie
An ex-CDCer who knows just enough to form dangerous opinons like these...