Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!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: <22756@cbmvax.commodore.com> Date: 28 Jun 91 03:19:39 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> <1135@stewart.UUCP> <1147@stewart.UUCP> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 67 In article <1147@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes: >daveh@cbmvax.commodore.com (Dave Haynie) writes: >>The unified cache is an obvious example >>of this -- Intel's even using split caches themselves in their other chips, >>because they simply result in better performance. >Are you suggesting that the unified cache is a limitation designed to ensure >MS-DOS compatibility? How would a split cache break MS-DOS? MS-DOS programs run self-modifying code out the wazoo. Separate I/D caches don't support this at all. Unified caches have no choice, of course, since they have no concept of what is data and what is program. >>Sorry Jerry, it isn't. The fact that the i860's data cache operates only in >>copy-back mode, and provides no snooping mechanisms, make it ill suited for >>use as a coprocessor, since all cache consistency must be handled in software >>alone, that's a significant performance hit. Both of these problems are >>apparently cured in the new chip. >And yet the i860 is used all over the place as a coprocessor, but only in a >couple of places as a CPU! I don't know enough about it, but it makes me >wonder. Actually, they rarely use it as a "coprocessor". More like a rather loosely coupled graphics engine, same basic function as a TI340x0, DSP, etc. In such an architecture, the i860 is restricted to a small chunk of memory which can be inefficiently shared, at least to some extent, by the host CPU. Sure, it works, you can build such a system with absolutely any processor. The C= A2232 card does this with a 4502 (6502 compatible), the BridgeCards of course work similarly with 8088/80286 processors. None of those were designed to work as coprocessors, and would make really bad tightly coupled processors. But in limited situations, anything can be used. That doesn't imply that the thing being used was designed to behave efficiently as a slave processor. >While I agree that the 486 instruction set is a bit dated, I wonder what you >mean by "simplified MMU". It does the job. How is it "simplified" or >"limited"? Simplified, in that its page table strategy requires more memory and more time to service than that of the 68040. Simplified in that its ATC is both smaller and less efficient that those of the 68040 (4 set rather than fully associative, as I recall). Simplified, in that there is no block translation feature, required for efficient mapping of things like display buffers without taking constant ATC hits. The list can go on. There is no secret here. Intel designers are certainly as up to date on the lastest computer architecture concepts as those at Motorola. The problem was simply that they had to leave out features because of all the architectural baggage they carry around supporting CPU 8086 "mode". There's only so much silicon available, and Intel had their hands tied in a way Motorola didn't. >I don't think so, Dave. You said, "It sucks because it's braindead." I said, >"Prove it." How was my reply foolish? Maybe your original statement was the >more foolish one? I said "it's bad". Sure, I didn't elaborate, this isn't comp.sys.amiga.hardware or comp.arch, and I see that after replying with backing proof, you still didn't understand the architecture you're arguing for well enough to appreciate my position. You said "no it isn't". That's a fair exchange with my unsupported argument. But you went on to ask for proof, without supplying any on your side of the argument. You still have yet to provide any. That's what I call a foolish argument, you can't win an debate by avoiding the issues. Unless maybe you're entering politics. -- 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.