gene@zeno.MN.ORG (Gene H. Olson) (09/02/88)
For some time now, I have been studying the available RISC architectures and have come to (what is to me) a startling and inescapable conclusion. The Japanese will win the RISC wars, they will win it with SPARC because SPARC will be cheaper, and will have equal or better performance than the others. The logic is as follows: * The Motorola, Intel, MIPS, SPARC, HP, and IBM RISC architectures are incredibly similar. In their basic instruction sets, none of them has any significant advantages over the other. All of them have a 32 bit register-to-register architecture. All of them have between 16 and 32 addressible registers. All of them are capable of 1.1 -> 1.5 cycles per instruction. All of them have similar virtual memory schemes for accessing the first 2 GB of user memory. Lets face it guys, you just can't do that much different with hardware instruction decoding. * What ultimately will make these machines faster is memory technology. Particularly cache memory technology. The Japanese know memory technology very well. * All of these architectures, except SPARC is proprietary. The US manufacturers who own the other architectures will attempt to take advantage of their propretary architectures to make high profits on their customers who are locked into those architectures. In particular they will not allow second source agreements until it is too late, and will milk their latest designs as cash cows to amuse stockholders, and justify development of the next generation. * No one will take a processor architecture seriously unless it has been designed in the US. This is a stupid and inane reality, like the reality that women are paid less than men, but it is true nonetheless. * The Japanese will embrace SPARC with a singular ferocity. The Japanese will realize that SPARC is their only opportunity to challenge the world market. They will sieze that opportunity captializing on their current advantage in memory technology. Their desire to cooperate within domestic industry, and their classic long-term outlook will cause them to produce a range of extremely compatible and price competitive products. * The US companies will do nothing. The US companies will see the awful truth in plenty of time to avoid it, but given the choice between high short-term profits, and intelligent long-term decisions will choose the former. * Driven by price realities in the market, OEMs throughout the world will choose Japanese SPARC processors. * Japanese SPARC will predominate. QED A word to the wise is sufficient. ----------- In case you are wondering, I have no affilitation with any of the above manufacturers. Gene H. Olson Smartware Consulting gene@zeno.mn.org amdahl!bungia!zeno!gene
rogerk@mips.COM (Roger B.A. Klorese) (09/02/88)
In article <58@zeno.MN.ORG> gene@zeno.UUCP (Gene H. Olson) writes: >* All of these (RISC) architectures, except SPARC is proprietary. > The US manufacturers who own the other architectures will > attempt to take advantage of their propretary architectures > to make high profits on their customers who are locked into > those architectures. In particular they will not allow > second source agreements until it is too late, and will > milk their latest designs as cash cows to amuse stockholders, > and justify development of the next generation. This displays a total lack of knowledge of the MIPS architecture and its availability. (Note: insert standard disclaimer here. I'm speaking for myself here.) The R3000 and R2000 processor series are *not* single-sourced, proprietary parts. They are not sold by MIPS, but rather, by several (currently three, and potentially more) semiconductor companies: Integrated Device Technology (IDT) LSI Logic Performance Semiconductor Unlike SPARC implementations, which are not all pin-compatible, all three implementations of the R3000 parts (and R2000 parts) are required by contract to be fully pin-compatible as well as opcode-compatible. That's not by choice, or by the convenience of the semiconductor vendors; it's in the very text of their license to manufacture. This competition is already driving prices down: some quoted prices are already down to half what they were at announcement in April. It seems that without pin-compatibility, there is no benefit to the builders of systems from mere opcode-compatibility. And without MMU compatibility (and, of course, SPARC offers your choice of two reference models), there is little benefit to systems software vendors. -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,prls,pyramid}!mips!rogerk 25 Burlington Mall Rd, Suite 300 rogerk@mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) Burlington, MA 01803 I don't think we're in toto any more, Kansas... +1 617 270-0613
mash@mips.COM (John Mashey) (09/03/88)
In article <58@zeno.MN.ORG> gene@zeno.UUCP (Gene H. Olson) writes: Gene states a number of authoritative-sounding facts, followed by some strong prognostications. Some of the facts are wrong, and need correction. Prognostications about the future must await the future; the best way to treat them is to save a copy, and look at it after time has passed, and more data available. As a service to the net, I'll keep a copy, so others need not do so, and repost it, adding lists of design wins; maybe every 6 months or so. >For some time now, I have been studying the available RISC >architectures and have come to (what is to me) a startling >and inescapable conclusion. The Japanese will win the >RISC wars, they will win it with SPARC because SPARC will >be cheaper, and will have equal or better performance than >the others. You might want to study a little harder. You may not have noticed that the 16.7MHz R2000 in the M/120 generally runs real programs 1.5X faster than the 16.7MHz SPARC in the Sun-4/200; but then it costs less, too. That's the current state of the world. >The logic is as follows: > >* The Motorola, Intel, MIPS, SPARC, HP, and IBM RISC > architectures are incredibly similar. In their basic > instruction sets, none of them has any significant > advantages over the other. > > All of them have a 32 bit register-to-register architecture. > All of them have between 16 and 32 addressible registers. There's a difference between 16 and 32. > All of them are capable of 1.1 -> 1.5 cycles per instruction. There's also a difference between 1.1 and 1.5. > Lets face it guys, you just can't do that much different > with hardware instruction decoding. Wait and see. >* What ultimately will make these machines faster is memory > technology. Particularly cache memory technology. This is probably true. > The Japanese know memory technology very well. > >* All of these architectures, except SPARC is proprietary. You also may not have noticed that there are already 3 suppliers of pin-compatible MIPS chips. >* The Japanese will embrace SPARC with a singular ferocity. Wait and see. >* Driven by price realities in the market, OEMs throughout the > world will choose Japanese SPARC processors. Wait and see. >* Japanese SPARC will predominate. Wait and see. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> 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
spp@zabriskie.uucp (Steve Pope) (09/03/88)
>> All of these (RISC) architectures, except SPARC is proprietary.
The government has chosen the MIPS architecture for several of its
programs partially based on the fact the architecture was not
proprietary. I can't visualize much commercial business developing
for a totally proprietary architecture either. You'd have to get
all your compiler writers to sign nondisclosures. Too much bother.
Is the Motorola 88000 architecture proprietary? What about the AMD
29000? In fact, could somebody name a RISC architecture that
*is* proprietary?
stevejohnl@ima.ima.isc.com (John R. Levine) (09/07/88)
In article <58@zeno.MN.ORG> gene@zeno.UUCP (Gene H. Olson) writes: >* The Japanese will embrace SPARC with a singular ferocity. > ... > Their desire to cooperate within domestic industry, and their > classic long-term outlook will cause them to produce a range > of extremely compatible and price competitive products. Given some of the extremely complicated and rather peculiar processor designs coming out of Japan these days under the auspices of the TRON project, I wouldn't hold my breath. The various TRON architectures aren't compatible with each other, either. See recent issues of IEEE Micro for details. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw
gene@zeno.MN.ORG (Gene H. Olson) (09/16/88)
Two weeks ago, I published the original article on this subject. The original was deliberately pompus to (sic) sparc controversy. I delayed in publishing a followup until I felt the ripples had died down. That article asserted that the Japanese would dominate the RISC markets because they would produce highly competetive non-proprietary SPARC products while US companies would cash in on customers locked into their proprietary architectures. There were some very helpful responses pointing out that the MIPS architecture is currently second and third sourced. They did not mention if MIPS was `open' in the sense that alternative competing implementations of the MIPS instruction set are welcomed. I assume not. The wide availability of second source chips seriously weakens my original argument. And I for one am encouraged that MIPS may continue to compete on price/performance in the marketplace. However: * The SPARC architecture is fully `open' in the sense that anyone may design a competitive processor or system of any sort without bothering to defeat architectural patents, and with the full co-operation of the original designers. So far as I know, this is a unique event in the history of computer design. It parallels (in my opinion) the openess of the UNIX operating system. Not that anyone cares, but I predicted the similar success of UNIX some 10 years ago. * So long as an architecture is kept proprietary, the owner of that architecture may choose at some point to cut off second sources, jack up prices, and go for profits. Intel chose to do this with the 386, and Motorola did so with the 68020 and 68030. Intel is currently engaged in a widely-publicised court battle with AMD to break their existing second source agreement covering the 386. * It is not terribly important who has the fastest current clock speed, instruction timings, or read/write cycle counts unless these features are locked in by the instruction set. All of the RISC chips are being sold on what they will be in a few years. Everyone is predicting 100 MIPs or so. Currently available chips are only hints of what is to come. * There was a heated discussion for awhile about register windows. No one pointed out that the SPARC architecture accesses register windows only with explicit instructions, that the architecture spec requires only two of them (one for user mode, one for software traps), and that they need not be otherwise used. SPARC offers you the option of register windows. If they don't help in some situations (they seem to work well in others) there is no reason you need use them. Since only two of them are required, there is no serious penalty if they are unused by an implementation. Its clearly a win-win situation. -------------- Bottom line Both manufactures and consumers of RISC chip products should be aware that we have dawned upon a new age in computer architectures. There will be at least one widely implemented, truly `open' standard. Any proprietary architecture (however well established) will be at a disadvantage to a well-informed consumer. DEC has been forced to loosten its grip on VMS and the VAX, IBM failed in promoting a PC-based 360 architecture (there was one), and Sperry (now UNISYS) is doing most of its expansion into UNIX. It happened in the operating system business. It *will* happen in the RISC processor business, and if you are foolish enough to ignore the trend, you will be left behind. The Japanese will be there in force. The USA can be there too. Its your choice. Gene H. Olson amdahl!bungia!zeno!gene Smartware Consulting gene@zeno.mn.org
andrew@jung.harlqn.uucp (Andrew Watson) (09/29/88)
In article <91@zeno.MN.ORG> gene@zeno.MN.ORG (Gene H. Olson) writes: [words about how SPARC, as a 'public domain' architecture, will sweep the board, just as unix, as semi-public domain software, has] * There was a heated discussion for awhile about register windows. No one pointed out that the SPARC architecture accesses register windows only with explicit instructions, that the architecture spec requires only two of them (one for user mode, one for software traps), and that they need not be otherwise used. SPARC offers you the option of register windows. If they don't help in some situations (they seem to work well in others) there is no reason you need use them. Since only two of them are required, there is no serious penalty if they are unused by an implementation. Its clearly a win-win situation. Just a small point from a compiler-writer who's been attempting to write a code generator for the SPARC that *does* ignore register windows - it's possible, but the architecture really doesn't support it. To explain - the whole point of windows is to minimise overall memory traffic by eliminating most stack read/writes. If the on-chip register file does overflow, then stack traffic is necessary, but the whole file can be dumped in one go, potentially using an efficient memory burst mode (on the 4/110, for instance). If you don't use windows, you have to emulate a stack yourself - not particularly difficult or slow, but it will cost you two instructions and a memory reference per push/pop, and three instructions for a call. A RISC without windows designed to use memory burst modes to boost performance is the Acorn ARM. It has a pair of instructions to push/pop an arbirary selection of its 16 (or is it 32?) registers in a single register-per-memory-cycle burst. Used in conjunction with a callee-saves calling convention, this allows one burst-mode access to the stack per call to save the return address, static link and all the registers that the callee wishes to use. -- Regards, Andrew. +-----------------------------------------------------------------------------+ | Andrew Watson, Harlequin Limited, andrew@uk.co.harlqn | | Barrington Hall, Barrington, Tel: +44 223 872522 | | Cambridge CB2 5RG, UK Fax: +44 223 872519 | +-----------------------------------------------------------------------------+
tim@crackle.amd.com (Tim Olson) (10/01/88)
In article <ANDREW.88Sep28160417@jung.harlqn.uucp> andrew@jung.harlqn.uucp (Andrew Watson) writes: | To explain - the whole point of windows is to minimise overall memory traffic | by eliminating most stack read/writes. If the on-chip register file does | overflow, then stack traffic is necessary, but the whole file can be dumped in | one go, potentially using an efficient memory burst mode (on the 4/110, for | instance). This is not the usual mode of operation. When a procedure call causes the stack cache to overflow, only the required amount of registers are saved to the stack (a single, fixed-sized frame for SPARC, or the exact number of registers required for Am29000) -- not the entire stack cache. This allows for a "hysterisis" effect whereby a "fill" is separated from the "spill" that caused it. For example, if the stack before a procedure call looked like: +-----+ | | | | Memory ~ ~ | | +-----+ <- rfb (register free boundary) | | | | Stack Cache (registers) |xxxxx| <- sp (current stack pointer) |xxxxx| +xxxxx+ <- rab (register allocate bound, == rfb - 512 bytes) xxxxx <- where sp needs to be after call (the xxxx marked area is the frame that needs to be allocated for the procedure we are calling). Since the allocation causes the sp to move below the rab, a "spill" occurs, moving enough registers from the rfb end of the stack cache into memory, and adjusting the rfb and rab pointers. After the call and spill, the stack looks like: +-----+ | | | | Memory ~ ~ <- old rfb pointed here | | +-----+ <- rfb (register free boundary) | | | | Stack cache (registers) | | | | +-----+ <- rab <- sp (both point to the same location) Now when we return from this procedure, we don't have to fill the spilled registers. In fact, we won't fill them until the sp crosses the rfb boundary. We can also now call this procedure again and not spill this time. This mechanism matches well with the typical call chain, which has a high degree of locality. Contrast this stack cache mechanism with a standard caller or callee saves convention -- there the registers are saved and restored from memory every time the procedure is called. -- Tim Olson Advanced Micro Devices (tim@crackle.amd.com)