Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site ucbcad.UUCP Path: utzoo!linus!genrad!mit-eddi!mit-vax!eagle!harpo!floyd!vax135!cornell!uw-beaver!tektronix!ucbcad!ucbesvax.turner From: ucbesvax.turner@ucbcad.UUCP Newsgroups: net.arch Subject: Re: RISC operating system - (nf) Message-ID: <116@ucbcad.UUCP> Date: Tue, 21-Jun-83 07:02:40 EDT Article-I.D.: ucbcad.116 Posted: Tue Jun 21 07:02:40 1983 Date-Received: Sun, 26-Jun-83 18:49:16 EDT Sender: notes@ucbcad.UUCP Organization: UC Berkeley, CAD Group Lines: 34 #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.turner