Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: MIPS, Compaq and Microsoft in bed - NYT story (TRY AGAIN, SORRY) Message-ID: <45777@mips.mips.COM> Date: 11 Feb 91 17:53:02 GMT References: <29920@usc> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 110 (sorry for previous repetition of posting; slip of the fingers). There have been all kinds of mis-apprehensions posted around here, so I'm not picking on this one, but will try to answer various things that accumulated over the weekend. First, let me address the mostly nontechnical issues that have been raised. 1. "The deal": READ MY MIPS No deal has been "announced" by Microsoft, COMPAQ, MIPS, SCO, DEC, or any combination thereof. Please do not refer to any of what's been published so far as an announcement. 2. "The R4000": READ MY MIPS AGAIN: It was announced, when it was announced, for the following reasons: a) Unlike systems (i.e., 360/95), chips take a while to design in, and so people want to know about them a lot earlier than is needed for systems products. (Although systems products also have varying lead times, i.e., everybody announces bigger systems further in advance than smaller ones, given the longer planning/budgeting lead times required.) b) Specifications, under NDA, have been available to key customers for quite a while; in fact, the R4000 has many features derived from customer input. c) For various reasons, when you talk about ANYTHING, it sooner or later leaks to your competitors, and if you don't talk about it, they do, and then you start seeing articles in the press about your own forthcoming products, but only filtered thru competitors, what you read is "interesting". (the one thing that appeared not to have leaked was the 64-bittedness issue, simply because we didn't really tell people about it....:-) d) If you hear the whole pitch, one of the things covered in detail is the 64-bit story, whose thesis is: 1) 32-bitness is going to become increasingly awkward for certain (important) application areas of micros over the next few years. 2) Software people are going to have to start NOW to consider the implications of bigger addressing, if they haven't already, or we'll be in the same silly state we were in with 4MB PDP-11/70s.... where each process could only address 128KB. After we looked at the inevitable sequence of how long things take, and the fact that most people expected 64-bit only in the 1993-1994 round of designs, we figured we'd better start getting the word out SOON. e) And finally, we're close enough on the design to be reasonably sure of the features that will be in the chip (i.e., read: it's laid out, it's being simulated like crazy (current count of CPU power used for verification == 1000-vax-mips), etc. (of course there is still uncertainty: if they find bugs from the last rounds of simulations and verifications, they'll fix them, and then have to run the verifications again.) (NOTE: it is hysterically funny to see a concern that little ol' MIPS might be overhanging the market with vapor and should be sued. Let's recall any of the following: Sun ECL SPARC announced in 1987, and decribed in technical papers in 1989, used as evidence of superior scalability "50MHz 486" ballyhooed to be delivered 4Q90, and widely-given Intel charts with 586, 686, etc.... Public 68040 presentations in mid-1988, 88110 presentations in 1990. IBM "technology" presentations early 4Q90, well before product availability. BTW: I'm not criticizing any of these at all by listing them here; but people should keep a sense of proportion :-) f) We were very careful to characterize this as a technology briefing, not a product announcement. Slater has already posted that of course the reality remains to be seen, but that we did provide substantial detail, i.e., not just a couple foils. You're likely to see much more detailed articles over time. g) There was one posting that this was desperation move, or some such. That's silly: we grew from $100M to $152M, in a rather tough year for computer companies, while fighting an all-out architecture war with companies much bigger than us, which is good for long-term success, but costs money in the short term. I.e., the R4000 was announced when it was because we're close, because we had to fix the misinformation, and because people need to start thinking about the surprises. In article <29920@usc> ajayshah@alhena.usc.edu (Ajay Shah) writes: >The article mentioned plans of going up to 50 mips using the new >technology. Isn't 50 mips pretty attainable using incremental >growth of implementation on top of SPARC/MIPS architectures? >Surely announcing a new architecture needs more justification >than performance like 50mips? Actually, all of the presentations have charts where it STARTS in that vicinity (and I'm vague on purpose; we won't know until we can give exact clock rates). REcall that R2000 -> R3000A started with 8MHz and went to 40MHz (sampling) with most of the design unchanged. REcall also that MIPS has always been willing to sacrifice optimal performance in the first round in order to get a design that shrinks and adapts well to coming process technologies. > >Is 64 bits important? IEEE doubles are 80 bits anyway; what >kinds of instructions will run a lot better with 64 bits? A lot >of integer-performance kind of work is manipulating small objects >(<= 32 bits) anyway, a wider bus wouldn't change anything. Or >would it? Look, the R4000 has a wider bus, but that's NOT what makes it a 64-bit chip. It's that because it has 64-bit integer registers and address generation. Recall that IBM S/370 and VAXen are 32-bit architectures, and have had varying size busses, including 64-bit, for years, without somebody claiming they were 64-bitters. Most of this confusion comes from calling the i860 64-bits. I'll post a separate 64-bit discussion later, with some more data. -- -john mashey DISCLAIMER: UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086