Path: utzoo!attcan!uunet!husc6!bbn!rochester!cornell!uw-beaver!teknowledge-vaxc!sri-unix!ctnews!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: RISC a short answer?? Message-ID: <2168@winchester.mips.COM> Date: 11 May 88 04:24:19 GMT References: <1036@nusdhub.UUCP> <1988May3.224604.2252@utzoo.uucp> <388@m3.mfci.UUCP> <6467@cit-vax.Caltech.Edu> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 36 In article <6467@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (Don Speck) writes: >Like it or not, we're stuck with the acronym. RISC used to mean > Reduced Instruction Set Complexity. >What we really want it to mean is: > Removal of Inherently Sequential Constructs. From this discussion, it must be that the half-life of folks on comp.arch is about a year, since I'd swear we went thru all of this a while back. But if not, here are more RISCs from talks we've been using for years: Reduced Instruction Set Computer maybe 10%; reducing is a side-effect of ruthlessly wanting something to go faster for a given cost, NOT a goal Reusable Information Storage Computer per Marty Hopkins: caches + enough regs for optimizer (>16); a better definition Revolutionary Innovation in the Science of Computing no way and the one we like the best, at least for VLSI part of computing: Response to Inherent Shifts in Computer technology HW: a) DRAMS get bigger, less penalty for large code b) SRAMS get faster/cheaper, hence caches cost-effective, even in microprocessor domain c) Cost-effective VLSI packages cross the threshold where you can support the CPU-cache bandwidth RISCs like, to get the speed they can give SW: d) Assembler->high-level languages, even on fairly small (PC-class) machines e) UNIX and other OS's now written in high-level languages -- -john mashey DISCLAIMER:UUCP: {ames,decwrl,prls,pyramid}!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