mash@mips.UUCP (John Mashey) (10/13/85)
jer@peora.UUCP (J. Eric Roskos) writes: > > For perspective, let us remember that one finds there [2nd Ed, 1982, p.335]: > > This approach of claiming that a major text in Computer Science is > discredited just because it took Intel's "preliminary" announcements on the > 432 as describing a completed product is not a very reasonable one. Myers' > text is well-known and respected. > > Likewise, the argument "the 432 didn't succeed, so the architectural > principles behind it are invalid" is a very common one among CISC-detractors, > but it makes little sense. Just because someone's implementation of an > architecture was unsuccessful doesn't mean the architecture is somehow > invalidated. Look at Multics vs. Unix. ***BEGIN ATTEMPT TO BE FAIRLY NEUTRAL*** 1) The intent wasn't to discredit the text, but, as I said, to keep perspective. If something claims X (object-oriented computers are the way to go), and uses example X1 (432) as a major support for X, and if X1 doesn't work out, then: a) X1's problems do not of themselves prove X is wrong, [as jer notes]. BUT b) One must at least partially discount X1 as a proof of X [the point of my original comment]. HOWEVER c) if over time, most examples, X2, X3,.... of X fail, then you start to wonder about whether X is right or not. 2) "Look at Multics vs Unix". I guess that this means that Multics and UNIX are unsuccessful/successful implementations of the same architecture. I always thought that UNIX a) propagated carefully chosen ideas from MULTICS, but b) was considered "in essence a modern implementation of MIT's CTSS" (dmr's UNIX Retrospective) c) left out a myriad of features deemed critical parts of MULTICS. ---- good place to stop if you don't want gory detail ----- 3) "preliminary" announcements: when the 2nd Edition was written, Myers was Manager of Microprocessor Architecture at Intel; although I have no data, I'd assume he had better information sources than "announcements". 4) "text is well-known and respected." This is probably true, but mostly irrelevant. Harlan Mills is well-known and I respect him; that doesn't make me believe in Chief Programmer Teams a lot. Since we've gotten into it this far, it might be worth more detailed comments on the Myers text for people who haven't read it. Note that it has a mixture of general thoughts about architecture, a passionate espousal of a particular viewpoint, and some case studies. I think the advice in Chapter 24 (Practice of Computer Architecture) is absolutely excellent [but weirdly, I think it reads a lot more like what RISC proponents say!] I think Chapters 1-5 raise good issues, and chapters 19-22 (Architectures for Databases) are interesting research areas. Chapters 11-12 describe the Burroughs B1700, an interesting commercial machine. [Also, there is discussion of other real Burroughs machines, and of the IBM S/38]. This is useful stuff, since these are real machines. Now we get to ones where there might be some question: Chapters 5-7 describe a purely paper design (Student-PL Machine). Chapters 8-10 describe SYMBOL, which was a worthy research experiment. However, that the company that built it (Fairchild) is into RISC these days. The Preface thanks Dave Ditzel for assistance, presumably for SYMBOL info. Unless Dave has changed his mind lately [Dave, are you out there?], he has been a vocal RISC proponent starting well before the SYMBOL retrospective referenced in Myers' book. Chapters 13-15 describe SWARD; that has some useful data; what isn't clear to me is where that work has gone since. [Does anybody know out there?] Chapters 16-18 describe the 432. He offers the following comparisons of SWARD and 432, labeled clearly as untested and therefore speculative: "1. Architecture complexity: lower in SWARD. 2. Hardware complexity: lower in 432. 3. Speed: better in SWARD... 4. Flexibility: higher in 432. 5. Risk: lower in 432." [!?!] My personal bottom-line on this is a) the book is worth looking at, b) it has fairly well-reasoned discussions of object-oriented systems c) it has some useful evidence for object-oriented hardware, but not [to me] compelling, since much of the book is dedicated to descriptions of a) a paper machine, b) 2 research experiments, of which at least one seems not to have been followed up c) a machine that failed despite massive efforts. Again, it is an issue of perspective: a lot of things sound good on paper, but the real proof is building real ones. ***END NEUTRALITY*** 6) I'm not exactly unbiased. I used to like deleting things from UNIX; I like giving "Small is Beautiful" talks; I work for a RISC-based company. 7) I have reservations about hardware that tries to do too much. The reservations come from a lot of past examples: a) Although I admire the innovative and gutsy design of the Burroughs B5000 and its successors, think about the cleverness and hardware resources that went into ALGOL-specific things like: Call-by-name Efficient addressing of variables in outer blocks Most people don't care much about the first; it was a subject of interminable articles because it was hard to understand, and hard to implement well, and not needed that much. For the second, a good optimizing compiler can handle the problem when it needs to; many people these days think that up-level addressing of variables is not a good idea anyway, and that good software engineering hides data rather than making it so visible. b) There are always hardware-vs-software tradeoffs, and comitting the wrong complexity to the hardware commits you forever, and doesn't make the complexity go away. I like Dave Ditzel's comments in COMPUTER 14, 7 (July 1981): "Building complex hardware is prone to the same bugs and fundamental design errors that plague complex software systems. Symbol contained many excellent and unique solutions ot individual problems, but the complex interactions of all these solutions made the entire system cumbersome and slow." c) Another good one is Bill Wulf's article "Compilers and Computer Architecture" in that same issue of COMPUTER: "Some architectures have provided direct implementations of high-level concepts. In many cases these turn out to be more trouble than they are worth." d) Compilers that do serious dataflow analysis and optimization already gather the data to optimize away much of the code for doing uninitialized-variable and subscript checks. You don't HAVE to have fancy hardware to do this, it's just one of the possible options. e) Smalltalk is of course a classic object-oriented system. Although implemented early on heavily-microcoded, complex machines, there is at least 1 pretty zingy implementation on garden-variety 68Ks, using clever software. 3) As before, many things sound good on paper, but fail when you really have to work out ALL of the details. At least (thank goodness), some of the RISC-vs-CISC debate ought to be settled by the end of 1986. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043