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