Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: 680x0 vs 80x86 Message-ID: <22764@cbmvax.commodore.com> Date: 28 Jun 91 06:41:15 GMT References: <92@ryptyde.UUCP> <4671.tnews@templar.actrix.gen.nz> <1154@stewart.UUCP> <1991Jun25.165516.13021@mintaka.lcs.mit.edu> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 97 In article kls30@DUTS.ccc.amdahl.com (PUT YOUR NAME HERE) writes: >In article <1991Jun25.165516.13021@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes: >> But this is different, Jerry, because in this case the OS KNOWS >>how to clear caches. If a lot of MS-DOG programs used self-modifying >>programs, or if the OS itself doesn't know how to treat caches, >>code will break. Hence, Intel probably keeping I&D unified to avoid >>an MS-DOG nightmare. >Wrong. Intel decided to go with a unified cache for one because it is >simpler to implement. Wrong. They did it for compatibility, plain and simple. The additional complexity of a split cache system is trivial compared to the work they went through buildin the rest of the '486 anyway. Plus, they've already proven they can handle it, in the i860 and i960. And they've also proven they're willing to share pieces between processors when applicable, as the i860 MMU demonstrates (it's basically the clean parts of the '386 MMU). >Also if you have a 4 way set assoc. cache you have basically 4 small caches. Of course you do. The set associtivity is a big win, and lets you have smaller MMU page sizes (you never want your tag index to consist of translated addresses). Same reason Motorola uses a 4 set associative cache design for both '040 caches. >Also in Intel processors you have instuctions that have data included or >immediately following. Kind of hard to separate data and instuctions. Not at all, works just dandy in Motorola processors, which certainly have the "immediate" addressing mode. Everything's coming from the same external memory anyway, the split cache simply gives you advantages: - Instruction streams are highly linear, data streams aren't always, and are very often located all over the place. With the split cache, data thrashing doesn't clobber your instruction caching. - Instruction and Data needed in very different stages of the machine pipeline. With the split cache, you get parallel cache access to both I and D, the unified cache by it's nature supports only sequential access. Should one cache miss, there's no cache/bus fetch contention as there would be with the unified cache. >Moto went with a seperate cache because the architecture is different. >The type of instructions are different. "MOVE.L #$0000,D0" sure looks to be just the kind of instruction you're claiming Intel needs to back up with its unified cache. There are certainly differences in instruction sets and architecture, but not to the extent you're claiming. The fact is, the '486 could have been a Harvard machine just as easily as the '040. The only thing that stopped it was code compatibility. UNIX wouldn't be any problem, and I imagine OS/2 wouldn't either, but MS-DOS would die in flames on such a machine. Intel only sells '486s because they run MS-DOS. So despite obvious and well understood architectural arguments to the contrary, sound marketing sense made the '486's cache unified. >As for self modifying code. The machines that use Moto processors are >more guilty of this. Not really. Sure, some bad programming is done on all OSs. There were even five or six Amiga programs which failed due to cache problems. But Motorola has been moving in the separate I/D cache direction since it first put an I cache on the '020 many, many moons ago. So Motorola system code has been, over all, much, much better than Intel system code. Not only that, but the Motorola market is fragmented, OS wise. Something that causes 30% if Atari programs to fail isn't death to Motorola as long as Apple, C=, UNIX, etc. are happy. >When Moto started putting small caches on their chips it created a nightmare. For whom? Certainly not for the Amiga. It didn't seem to be much of a problem for Sun, HP, or Apple either. Atari's list of problems begins with "F-line exceptions used for OS function traps"; even if they have problems with cache, that's the least of their worries. >Self modifying code would have broken the 386 with cache. It doesn't have to. All '386s have external caches, by their nature unified. Any D to I transform is consistent within such a cache, so self-modifying code is absolutely no problem. >Also if a cache is designed properly it should be completly transparent to >software. If you have the proper OS support, they are. Caches are never fully transparent to the OS. MS-DOS has the unique problem of having no OS to manage any caching for the applications programs, so only very simple cache designs are successful. Separate I/D caches are completely transparent under UNIX, since memory pages are specifically allocated as text and data, and any writes to text pages are trapped by the MMU. Amiga, and presumably Mac, OSs have sufficient OS support to transparently manage most of the caching problems that would get you under MS-DOS. However, self-modifying code will cause untrapped program failures under AmigaOS, rather than trapped program failures under UNIX. -- 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.