Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!stanford.edu!neon.Stanford.EDU!torrie From: torrie@cs.stanford.edu (Evan Torrie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: 680x0 vs 80x86 Message-ID: <1991Jun27.064123.27492@neon.Stanford.EDU> Date: 27 Jun 91 06:41:23 GMT References: <92@ryptyde.UUCP> <4671.tnews@templar.actrix.gen.nz> <1154@stewart.UUCP> <1991Jun25.165516.13021@mintaka.lcs.mit.edu> Sender: torrie@neon.Stanford.EDU (Evan James Torrie) Organization: Computer Science Department, Stanford University, Ca , USA Lines: 60 kls30@duts.ccc.amdahl.com (Kent L Shephard) 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. Also if you have a 4 way set assoc. cache you >have basically 4 small caches. But you still have only one internal path from the CPU to the cache, thus cutting your bandwidth in half vs a split I/D Harvard architecture. For an example of why this is important, check out the parallelism in any of today's microprocessors' pipelines. Does Intel still use their 386 instruction prefetch buffer in the 486? I suppose that should shore up some of the performance loss from having a unified cache. >Also in Intel processors you have >instuctions that have data included or immediately following. Kind of >hard to separate data and instuctions. An example of such an instruction? The 68K has data in its instructions, the ADDQ #x, Dn for example, but this doesn't stop an I/D cache (since the data is non-modifiable). >Moto went with a seperate cache because the architecture is different. >The type of instructions are different. Moto went with separate caches because of their performance. >As for self modifying code. The machines that use Moto processors are >more guilty of this. The Mac and Atari machines uses self modifying code >for copy protection. When Moto started putting small caches on their >chips it created a nightmare. So the copy-protection schemes don't use self-modifying code anymore [in fact, most Mac programs don't use copy-protection other than manual-type methods]. At least Motorola could do this, unlike Intel. >Self modifying code would have broken the 386 with cache. Not with a unified cache. >Also if a cache is designed properly it should be completly transparent to >software. Transparent to user software, perhaps, but often the OS has to be intimately aware of the cache, just as it has to be aware of the TLB. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Murphy's Law of Intelism: Just when you thought Intel had done everything possible to pervert the course of computer architecture, they bring out the 860