Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: The 68050 - end of the 680x0? (was Re: The Amiga's Future) Message-ID: <22460@cbmvax.commodore.com> Date: 14 Jun 91 17:02:06 GMT References: <5068@orbit.cts.com> <16647@darkstar.ucsc.edu> < <1308@cbmger.UUCP> <28@ryptyde.UUCP> > <01dH!cmr@cs.psu.edu> <1991Jun10.072945.8821@neon.Stanford.EDU> <22365@cbmvax.commodore.com> <1991Jun13.003707.19785@neon.Stanford.EDU> <2 Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 93 In article <1991Jun14.004412.26009@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: >daveh@cbmvax.commodore.com (Dave Haynie) writes: >>Burst mode helps some, but it's no substitute for 0 wait state memory. Cache > Wouldn't this also be true for a 68020 system? No. The 68020 doesn't support burst mode. It also has a minimal cycle time of three clocks. If you add the 68851 MMU (like A2620 or original Mac II, for 68030 equivalence), the minimum cycle time becomes four clocks. The 68030's minimum memory cycle time is 2 clocks (burst averages 1.25 clocks, but it can do unnecessary fetches). >>They're continuing to push the i860 and i960 into their established niches. >>The i860 as a graphics coprocessor and vector machine (it is showing up on >>all kinds of high end display boards), the i960 for embedded control, >>especially in the military and avionics markets. > Yes, but I meant that Intel would use the "expertise" gathered from >developing these processors in designing the 586. That's no different that Motorola using what it learns on the 96002 and 88000 for future 680x0 family members. In fact, there's more than a passing resembelence between the 68040 and the 88100/88200 in a number of areas. Rumor has it the on-chip 88110 cache will be as fast as the 68040's (currently 88200s hit in two clocks, like the 68030, rather than the single clock of the 68040). >>Well, no one else does :-) (EE Times was lukewarm on it, Microprocessor Report >>pretty unimpressed, since it doesn't really mean much of anything yet). > "Yet" is the important word. Sure, it's all vapourware at the moment, >but I think the point of announcing it now was to scare Intel. I really don't think so. No one in the group has a good reason to scare Intel. You might argue for Compaq wanting better Intel CPUs, maybe they're not so concerned if they're committed to ACE. DEC and SGI certainly have no motive in getting Intel excited, neither do Microsoft or MIPS. >>No, actually, it's Compaq trying to get out from behind Intel and IBM with >>something they can control. > I don't see why Compaq will be able to control this any better than the >80x86 market, if they're agreeing to all these other firms as ACE members. Compaq is one of the leaders. They're getting their two cents in now, at the start, and making it happen. Compaq and DEC are in the IBM position themselves with this. Even if it's set up as a cooperative rather than "IBM and Intel do, the rest of you follow", Compaq's better off. Also, keep in mind that Compaq is selling at the high end of the PClone market now. They are having problems with cheap, lower end systems just like IBM. It's real obvious they're not going to turn around and try to be a Tandy or Tawian, Inc. So moving upward is a logical thing for them. Especially a move to the R4000, which Intel can't possibly catch with any new 80x86 processor (heck, the best '486s don't get near today's R3001s). > I still think Compaq would prefer to stay with the 80x86 family >[at least that's the impression I got as to why ACE included the 80x86 >as a valid architecture, rather than sticking strictly with the R4000]. I think that was done, more than anything, for software reasons. If you make high end PClones ACE compatible, at the source level (actually, it's more like specifying the ACE system as being compatible in the first place, since this Intel stuff already exists), then you get a free flow of software from the extremely large PClone market, since porting to the MIPS machines will be a piece of cake. > Current 68K users are unlikely to go the SPARC route, given its poor >performance and relatively poor architecture. [You'll note that a lot >of 80x86 vendors are now selling SPARC systems - I guess they know how >to pick a bad one :-)]. I guess Sun would be a little surprised to hear that, since they replaced the 68K with SPARC, and in fact, really hadn't quite "taken off" as a major force in the workstation market until they did. But I do agree that the SPARC architecture is weak when compared to the current alternatives. Clone makers don't care about that, they're not going to go out and build a brand new computer based on 88110 or R4000 or any merchant PA-RISC that they can eventually do. They're going to copy something. SPARC machines are faster than 80x86s, and Sun's making it easy for these guys to make these copies (of course, not real fast ones, but the low end systems). >MIPS is definitely Motorola's biggest threat, especially if Motorola doesn't >get the 88110 out and shipping soon after the R4000. I agree there, they are the two I would look at if I had to start building a RISC system this year. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "This is my mistake. Let me make it good." -R.E.M.