Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!unido!mpirbn!p554mve From: p554mve@mpirbn.UUCP (Michael van Elst) Newsgroups: comp.sys.amiga.hardware Subject: Re: Cheap CPU cache (was Re: A500/14 MHz 68k?) Message-ID: <1004@mpirbn.UUCP> Date: 9 May 90 19:59:21 GMT References: <8903@chaph.usc.edu> <10630@cbmvax.commodore.com> <3596@pikes.Colorado.EDU> <3673@minyos.xx.rmit.oz> <943@mpirbn.UUCP> <948@mpirbn.UUCP> <11458@cbmvax.commodore.com> Reply-To: p554mve@mpirbn.UUCP (Michael van Elst) Organization: Max-Planck-Institut fuer Radioastronomie, Bonn Lines: 48 In article <11458@cbmvax.commodore.com> grr@cbmvax (George Robbins) writes: >In article <948@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes: >> In article brent@asparagine.phri.nyu.edu (Brent Hobbs) writes: >> >In article <943@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes: >> >> A second approach does give about 70-80% speedup on average programs and >> >> will affect kickstart operations as well. This is a cache for the CPU. >> The design is published in the german magazine 'ST Computer' from >> 'Markt&Technik'. >For curiousity's sake, do you know what issue this was in? It's a little >hard to search though German magazines from here... >Personally, I'd have to wonder about the wisdom of a cacheing scheme - I'd >expect the cost/complexity to be about the same as implementing a fast DRAM >system... That's the last (May) issue. And I've mistaken the publisher, it's the 'Heim-Verlag'. The writers work for a company ("Maxon") that sells these hardware projects. There was a 'slow-scan' 4-greyscale video digitizer too. Now, the main reason for a cache is that either the exisiting ram isn't fast enough or there isn't fast ram available. The approach uses a so called 'direct-mapped' cache that is easy to build together with a 16MHz clocked CPU. This type cache divides the physical memory into pages as large as the cache. Each address might be mapped to a memory cell within the cache by stripping the upper address bits. Two (or more) addresses on different pages that have common lower address bits are mapped to the same cache. A very fast 'tag' ram holds the pagenumber of the address that is currently in the cache. When the cpu accesses an address you can find a valid cache entry and disable the data strobe for the main memory. Or you get a cache 'miss' and write the data into the appropriate cache cells when the main memory returns the data after two wait states. Writes are done 'through' the cache. They will need two waits everytime. Ugh. Other people might explain it better. In the PC-world, fast machines use a better cache algorithm (implemented in the intel cache controller most times). Nevertheless, our DEC3100 uses a direct-mapped cache too. There are some profiling tools that help placing program segments into each memory 'page' to avoid cache thrashing. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."