Article 49093 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!msus1.msus.edu!TIGGER.STCLOUD.MSUS.EDU!LKOOP Newsgroups: comp.sys.amiga.hardware Subject: Re: What do the caches on a 68030 do? Message-ID: <1993Aug27.164908.5233@msus1.msus.edu> From: lkoop@TIGGER.STCLOUD.MSUS.EDU (LaMonte Koop) Date: 27 Aug 93 16:49:07 -0600 Reply-To: lkoop@TIGGER.STCLOUD.MSUS.EDU References: <25l1u3$6om@beta.qmw.ac.uk> Organization: AIBB Performance Analysis Development Nntp-Posting-Host: tigger.stcloud.msus.edu Lines: 63 In article <25l1u3$6om@beta.qmw.ac.uk>, d.a.gill@qmw.ac.uk writes: >Hi, > I know that the 68030 in my A4000/030 has internal >data and instruction caches. I know that the CPU program >can be used to switch them on and off. My question is this. >What do they actually do? Will they speed the system up? >If so, by how much. Will they crash with some software? > >Thanks > >Dave [d.a.gill@qmw.ac.uk] Basically, the caches are used to place instructions and data into very fast storage mediums on-chip so that subsequent accesses to the same instructions and data will go to the cache instead of external memory. The idea is this: Most programs spend a great deal of time within fairly small localized code loops and often use data from a few memory locations repeatedly. By taking these instructions/data and storing them in the caches and subsequently using those images, the CPU can access these generally with no wait whatsoever. On the other hand, taking the instructions/ data from memory usually requires some waiting on the CPU's part for the memory to return the data needed. In this way, caches provide a speed increase for a system over a non-cached system. The way a cache works in this case is somewhat like this: When the CPU needs to access something from memory, it first checks the appropriate cache to determine if an image is resident there. If so, it uses that and goes on. If the data/instruction was not in the cache, the CPU then reads the data/instruction from memory, and also puts a copy in the cache for use later, thus allowing subsequent accesses to the same data/instruction to be done in a much quicker manner. (Now, the actual cache "filling" policy varies depending on the cache implementation). Now, as for caches causing system failures, for the most part, the answer is "no". They are designed to be software transparent so the any software running doesn't even know the caches exist. However, there are certain circumstances where improperly designed software can cause problems with a cache. One such example is self-modifying code. If a program modifies its own instructions, it may end up modifying the copy found in memory itself -- if the CPU has already cached these instructions it will use the cache copy, which has not been modified, and thus the software will not behave as intended. Programs which use self-modifying code need to be aware of this and perform the proper cache maintenance to avoid this problem. Another type of problem which crops up has to do with "copyback" or "writeback" cache designs, such as that found on the 68040's data cache. In these designs writes to memory are stored in the cache if a cache "hit" occurs, (data was found in the cache) and the memory itself is not updated until the cache is told to write its contents back to memory. This is in contrast to many "write through" designs, which automatically update both the cache and memory when a write operation occurs on data stored in the cache. (The advantage to a "copyback" design is that the CPU need not access memory on every write -- this creates a performance benefit). Now, the problem than can arise with a copyback setup can be visualized like this: Suppose a program writes out some data for a DMA device (direct memory access) to read. Now, if that data was already in the cache, the modified version will be written to the cache only, and thus the DMA device will go to memory and get "stale" data -- the unmodified version. This is generally handled by system software by telling the cache to write its contents back to memory. ---------------------------------------- LaMonte Koop -- SCS Electrical/Computer Engineering Internet: lkoop@tigger.stcloud.msus.edu -OR- f00012@kanga.stcloud.msus.edu "Performance is in the eye of the beholder" --------------------------------------------------------------------------- Article 49193 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!spool.mu.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!metro!news.cs.uow.edu.au!news.cs.uow.edu.au!not-for-mail From: u9152083@wyvern.cs.uow.edu.au (Glen Justin Balmer) Newsgroups: comp.sys.amiga.hardware Subject: Re: What do the caches on a 68030 do? Date: 30 Aug 1993 19:02:52 +1000 Organization: University of Wollongong, NSW, Australia. Lines: 50 Message-ID: <25sfns$rj3@wyvern.cs.uow.edu.au> References: <25l1u3$6om@beta.qmw.ac.uk> NNTP-Posting-Host: wyvern.cs.uow.edu.au d.a.gill@qmw.ac.uk writes: > I know that the 68030 in my A4000/030 has internal >data and instruction caches. I know that the CPU program >can be used to switch them on and off. >My question is this. >What do they actually do? Instruction caches are used by the processor to keep a 'batch' of instructions iternally. Data caches are used in same way but keep 'batch' of current data internally. >Will they speed the system up? A normal CPU without cache has to fetch the instruction from memory, then whatever data from memory as well. Each instruction and data fetch directly from memory requires the CPU to 'wait' for the memory read cycle time to finish. A cache-using CPU fetch's a 'batch' of instruction's from memory, and a 'batch' of the data from memory as well (The data that the 'batch' of instr's uses). Since the cache-using CPU fetch's a 'batch' of instructions, the CPU only has to wait for 1 memory read cycle time. Then the CPU can use internal busses for instruction and data execution. In one word : cache's speed up the system dramatically, that is why most new CPU's use big separate data and instruction cache's. >If so, by how much? It depends on the cache-pipelining used. (consult a computer architecture textbook or something) >Will they crash with some software? NO. The CPU handles all cache and pipelining 'routines'. NOBODY can change it unless they do some VLSI hardwiring..... Bye Glen Balmer u9152083@wyvern.cs.uow.edu.au 2nd/3rd Year Computer Engineering University Of Wollongong These answers are based on thoughts, knowledge, and plenty of partying... Article 39040 of comp.sys.amiga.programmer: Newsgroups: comp.sys.amiga.programmer Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!news-feed-1.peachnet.edu!concert!sas!mozart.unx.sas.com!jamie From: jamie@cdevil.unx.sas.com (James Cooper) Subject: Re: cache-friendly programming: how is it done? Originator: jamie@cdevil.unx.sas.com Sender: news@unx.sas.com (Noter of Newsworthy Events) Message-ID: Date: Thu, 21 Oct 1993 13:22:38 GMT References: <2a48rj$cn@lll-winken.llnl.gov> Nntp-Posting-Host: cdevil.unx.sas.com Organization: SAS Institute Inc. Lines: 36 In article <2a48rj$cn@lll-winken.llnl.gov>, u70007@windsurf.nersc.gov (Eric Salo) writes: >Everyone knows that one of the big problems with old Amiga software is that >there's a good chance you'll need to turn off your caches if you want to >run it on an accelerated machine. Well, I'm putting the finishing touches >on a game and I strongly suspect that won't work with a cache. My intuition >tells me that the DMA + cache = trouble, but I'm completely ignorant about >what needs to be done. Could someone please educate me? I don't have the 2.0 >RKM, but a specific reference to it would be just fine. Thanks. There are really only 2 things you need to be sure of in regards to caches: 1) DO NOT use self-modifying code. If you do, the caches will have to be turned off. Its just plain bad programming in most cases, as well. 2) If you spawn any tasks, flush the cache immediately before the CreateProc call. The only other minor nit is if you embed data in your code section, you could have problems... unless you are so tight on space you can't do it any other way, it is better to collect your data into a different hunk entirely. I'm sure you could find any number of people with accellerated machines to test your program before you release it. I myself have both an A3000 and an A4000 available... :-) -- --------------- Jim Cooper (jamie@unx.sas.com) bix: jcooper Any opinions expressed herein are mine (Mine, all mine! Ha, ha, ha!), and not necessarily those of my employer. Article 39057 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!netnews.nwnet.net!news.clark.edu!spool.mu.edu!howland.reston.ans.net!xlink.net!rz.uni-karlsruhe.de!stepsun.uni-kl.de!uklirb!feck From: feck@informatik.uni-kl.de (Christoph Feck IRZ) Newsgroups: comp.sys.amiga.programmer Subject: Re: cache-friendly programming: how is it done? Message-ID: <1993Oct21.161549@informatik.uni-kl.de> Date: 21 Oct 93 15:15:48 GMT Article-I.D.: informat.1993Oct21.161549 References: <2a48rj$cn@lll-winken.llnl.gov> Sender: news@uklirb.informatik.uni-kl.de (Unix-News-System) Organization: University of Kaiserslautern Lines: 19 Nntp-Posting-Host: uklirb.informatik.uni-kl.de In article , jamie@cdevil.unx.sas.com (James Cooper) writes: > > There are really only 2 things you need to be sure of in regards to > caches: > > 1) DO NOT use self-modifying code. If you do, the caches will > have to be turned off. Its just plain bad programming in > most cases, as well. Yes it is bad, but turning it off is not required. Flushing it after the modification is sufficient. > 2) If you spawn any tasks, flush the cache immediately before > the CreateProc call. Why? Where is this documented? Just curious... 3k// Christoph Feck, TowerSystems \X/ Pepo@IRC