Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!pyramid!prls!mips!mash From: mash@mips.UUCP Newsgroups: comp.arch Subject: Re: What should be in hardware but isn't Message-ID: <704@winchester.UUCP> Date: Thu, 24-Sep-87 11:35:16 EDT Article-I.D.: winchest.704 Posted: Thu Sep 24 11:35:16 1987 Date-Received: Sat, 26-Sep-87 13:30:23 EDT References: <581@l.cc.purdue.edu> <18336@amdcad.AMD.COM> <582@l.cc.purdue.edu> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 82 In article <582@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: ....general discussion of wishlists of things that should be in hardware; more support for various flavors of multiply/divide, bit manipulation, etc. >Olson greatly underestimates the number of RISC instructions needed to do >even a fair job. If the user is going to be able to do the things needed >efficiently, the combining of instructions must be done at the "nanocode" >level. Frankly, I think that having thousands of instructions, arranged >so that decoding patterns can be used, is much easier. ... Earlier, Herman had written: >There are many instructions which are easy to implement in hardware, but >for which software implementation may even be so costly that a procedure >using the instruction may be worthless. Some of these instructions have >been implemented in the past and have died because the ill-designed >languages do not even recognize their existence. Others have not been >included due to the non-recognition of them by the so-called experts and >by the stupid attitude that something should not be implemented unless >99.99% of the users of the machine should be able to want the instruction >_now_. As you can tell from this article, I consider the present CISC >computers to be RISCy.... Sigh. There is a useful point embedded here, but it sounds like a topic I'd thought beaten to death in this newsgroup has to be reviewed one more time. Legitimate point: a) If an operation is not supported in hardware, AND IF b) Doing it in software takes a lot longer, AND IF c) Programs use that operation with high dynamic frequency, THEN d) Providing that operation in hardware might be worthwhile. For example, there have been some ludicrous statements in the press about "RISC machines can't do floating point": if floating point is important to you, you'd better include it in the instruction set. However, the general approach (anecdotal) is not the way people design computers, these days, and for good reason. As noted before here, a plausible way to design a computer is: 1) Pick a REPRESENTATIVE set of benchmarks. 2) Do a first-cut architecture, based on past experience. 3) Do compilers. 4) Add or delete features, measuring the impact by running compiled/assembled code through architectural simulators. 5) Iterate until you can't find anything else to add that actually improves performance by some noticeable amount, or until you run out of time. This is not a perfect recipe, of course. For example, if the benchmark set is chosen poorly, bad surprises will happen. However, what people don't do these days, is design architectures by saying "I remember code where it would have been handy to have operation X, which was stupidly not provided. Let's add it." What's needed to be useful, is NOT a list of anecdotes about features that might be useful in some cases [and indeed, they might], or that look interesting when one reads the instruction manuals, or that look like they save a few cycles here or there in the context of small code sequences, but hard DATA about the benefits of including them. For example, much more useful to people who design computers is reasoning like: 1) Here is a specific application program, or even better, this known to be typical of an important class of applications. 2) Running on a computer that lacks feature X, with appropriate instrumentation, we've found that the addition of X would reduce the runtime by Y%. One of the other comments wished to have back the UNIVAC-style addressing of registers, with no backup for why this would be good. As it happens: a) This can be costly in hardwre, especially in single-chip implementations, unless the whole architecture is built around it (like CRISP). b) It can complexify life for optimizing compilers. Show us some data why this feature is worth more than it hurts. Data, not anecdots. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086