bcase@uiucdcs.UUCP (06/16/83)
#N:uiucdcs:27800010:000:1394
uiucdcs!bcase Jun 15 23:54:00 1983
This is nothing important, just an observation.
While reading the UNIX (tm Bell Labs) issue of the BSTJ and writing
my thesis (on RISC architectures) concurrently, the following lines
from "UNIX Implementation" stuck in my mind:
The kernel is the only UNIX code that cannot be substituted
by a user to his own liking. For this reason, the kernel
should make as few real decisions as possible. This does not
mean to allow the user a million options to do the same thing.
Rather, it means to allow only one way to do one thing, but
have that way be the least-common divisor of all the options
that might have been provided.
If "hardware" is substituted for "kernel" and "compiler" for "user,"
then these remarks begin to sound a lot like some comments from
a paper by Wulf, "Compilers and Computer Architecture" (IEEE Computer,
July 1981):
- One vs. all. There should be precisely one way to do something,
or all ways should be possible.
- Provide primitives, not solutions. It is far better to provide
good primitives from which solutions to code generation problems
can be synthesized than to provide the solutions themselves.
So there it is. The basis for RISC architectures was present all along
in the design of the UNIX operating system. Does this make UNIX the
RISC operating system? Sure does.... Thanks Ken and Dennis.Anonymous@inmet.UUCP (06/19/83)
#R:uiucdcs:27800010:inmet:2500001:000:37 inmet!Anonymous Jun 18 11:14:00 1983 Excuse my ignorance: What is RISC??
mark@umcp-cs.UUCP (06/21/83)
Reduced Instruction Set Computer.
--
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@UDel-Relayucbesvax.turner@ucbcad.UUCP (06/21/83)
#R:uiucdcs:27800010:ucbesvax:12800002:000:1522
ucbesvax!turner Jun 21 01:06:00 1983
Some comments on the UNIX/RISC comparison:
- UNIX as a RISC OS? I think this is mostly an outgrowth of the
decision to have (essentially) two kinds of files: i-nodes and
strings of bytes in blocks. It is worth noting, however, that
one does result in an efficient file-system by any means. It is
one of UNIX's recognized failings. The remedies for this are
by no means simple. (Although some of these DO help enormously.)
- The idea behind RISC (if I understand it correctly) is that there
is performance to be gained in simplifying the control logic.
In the case of Berkeley RISC's, the case had been made fairly well.
(It is amusing when uP designers from industry look at the RISC I/II
layouts and search vainly for ROM.) In UNIX, however, the "control
logic" is undeniably simpler than that of systems of supposedly
equivalent power, but where is the performance gain?
- In RISC I/II, the space that might be filled with microcode ROM is
instead taken up by register files. The case for RISCs lies almost
entirely in what one does with leftover capacity. At Berkeley, this
space was taken up by what is essentially a very specialized on-chip
cache memory.
Well, I didn't start out with any particular point to make. I don't think
that the comparison is unduly stretched. Perhaps the real performance
gain in UNIX is that it tends to optimize programming.
Michael Turner
ucbvax!esvax.turnerbcase@uiucdcs.UUCP (06/28/83)
#R:uiucdcs:27800010:uiucdcs:27800013:000:635
uiucdcs!bcase Jun 27 19:09:00 1983
Oops. I didn't mean to say that UNIX is perfect for the Berkeley RISC
machine. What I meant to say is that the design of UNIX and the design
of the RISC share some common ground, and the ground they share is
important ground. When I say 'RISC' I am usually using it in a generic
sense. I forgot that the rest of the world may not think that way....
The important idea is that the instruction set of a computer should provide
the compiler with tools for implementing the semantics of a program.
The best part about UNIX is that it gives the user so many useful tools
with which to solve problems. That's the connection.
bcase