Path: utzoo!mnetor!uunet!husc6!think!bloom-beacon!gatech!purdue!umd5!uvaarpa!virginia!uvacs!wulf
From: wulf@uvacs.CS.VIRGINIA.EDU (Bill Wulf)
Newsgroups: comp.arch
Subject: Re: The WM Machine (continued)
Message-ID: <2388@uvacs.CS.VIRGINIA.EDU>
Date: 6 May 88 17:41:46 GMT
References: <5339@aw.sei.cmu.edu> <9331@apple.Apple.Com>
Reply-To: wulf@uvacs.cs.virginia.edu.UUCP (Bill Wulf)
Organization: U.Va. CS dept.  Charlottesville, VA
Lines: 46

[As I was editing my last message, our VAX went down -- somehow the
air conditioning had gotten turned off, and the VAX was at risk of a 
melt-down. Anyway, I was editing the middle of the message, and had
just said that I didn't have space to describe the OS support
features. What I would have said next was ...]

... I am putting the finishing touches on the arch. definition, and
hope to make it available as a UVa report in the next few weeks. I'll
be happy to mail it to folks who send me a request -- it will tell you
a lot more than you probably want to know. Briefly, however, there are
really two aspects that I might mention here.

First, note the class of "special" instructions isn't described in
the paper. Basically the instructions in this class (which includes the
OS support stuff) take multiple cycles and are sorta CISC-ish ( I HATE
these labels; people get all hung up on the labels at the expense of
the substance). They are segregated this way so that the nornal decode-ex
path is not delayed by them. They in turn, translate into a sequence
of the simpler (RISC-ish) instructions. They take as long as they take!
They could not be faster inplemented another way, they do not slow down
the other, more common, instructions, and they can safely manipulate
state (in prescribed, safe ways) that is not normally accessible
in another way (eg, the FIFO state).

Second, I wanted to provide a set of support for OS functions that
provides an overall speedup without impacting the cycle time -- I didn't
want to build a 100MIPS processor, and then throw away 30-50% of it
on OS related stuff. The best way I know how to do that is to make
more OS-ish operations directly, and SAFELY, available from normal
user code (as opposed to "kernel mode"), thus avoiding the considerable
overhead of kernel entry/exit. I think we have found a simple and elegant
way to do that -- one that, in fact, eliminates kernel mode altogether.

BAsically, the scheme involves typing pages, interpreting the rights
bits differently for each type, and restricting certain operations to
operate on certain types of pages. For example, TCB (Task Control
Block) is a hardware understood page type. There is a Context-Swap
instruction that must name a TCB page as it's operand -- and to be
executed, must have the rights bits set appropriately. The net effect
is that it's possible (NOT required) to allow an ordinary user program
to act as a scheduler for a set of tasks (eg, it might be an Ada
runtime system), even though that program has no other privledges wrt
the tasks it schedules (eg, it can't access the code/data of the
tasks, modify their TCBs, etc.)

Bill