Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!styx!elxsi!beatnix!rw
From: rw@beatnix.UUCP
Newsgroups: comp.arch
Subject: Re: register window machine questions (really user mode I/O drivers)
Message-ID: <289@elxsi.UUCP>
Date: Fri, 27-Feb-87 11:56:14 EST
Article-I.D.: elxsi.289
Posted: Fri Feb 27 11:56:14 1987
Date-Received: Sun, 1-Mar-87 10:21:21 EST
References: <4376@columbia.UUCP> <448@cpocd2.UUCP> <5763@amdahl.UUCP>
Sender: nobody@elxsi.UUCP
Reply-To: rw@beatnix.UUCP (Russell Williams)
Organization: ELXSI Super Computers, San Jose
Lines: 44

In article <5763@amdahl.UUCP> chuck@amdahl.UUCP (Charles Simmons) writes:
>
>I agree with this, so I'm going to change the subject slightly.  Lately
>I've been thinking about operating systems which would perform a complete
>context switch on every interrupt.  In particular, code for handling
>interrupts would run in a restricted environment (ie user mode) where 
>their ability to accidentally trash other interrupt handlers, the operating 
>system, and device drivers would be minimized.
>
>My biggest problem with this concept is that context switching, even
>on a machine with "only" 16 registers is extremely expensive.
>I'd be interested in hearing about architechtures that minimize the
>expense of a context switch.

In Embos (Elxsi Message Based Operating System), I/O drivers (called access
managers) are user processes.  Everything is a "user process" -- there are
no priveleged instructions.  While there are intra-process interrupts, they
are not used to implement I/O.  I/O is done through normal use of the message
system.  I/O controllers look like software processes, and the access managers
just send and receive messages with them.  This makes debugging AMs for new
controllers easy because you can simulate the controller in software
transparently to the AM.

The Elxsi architecture has 16 (64 bit) GPRs per process.  The current implemen-
tation has 15 register sets (each set is a GPR plus other process context).  A
process in each CPU called the register set manager tries to keep all register
sets filled with ready-to-run processes.  Context switches between processes
in register sets are done by the microcode in about 10 microseconds.  This
number, while true, isn't very significant, since the first thing an AM does 
when dispatched to handle an I/O completion message is a receive instruction, 
and that takes about another 60 microseconds.  You could speed this up without
affecting the context switch time, though.  Even in a machine without multiple
register sets, you could easily get a suitably fast context switch given
appropriate hardware and/or microcode support. Multiple register sets just
turned out to be the best way for our situation.

So Elxsi is toward the other end of the spectrum of the lots of registers per
process context vs. lots of process contexts tradeoff.  But of course those
things are influenced by the kind of machine too.  You'd expect different
choices for a large, lots-of-users, multi-CPU machine implemented on 3 giant
ECL boards than for a single chip single-or-few-user machine.

Russell Williams
..!{sun|styx}!elxsi!rw