brent@asparagine.phri.nyu.edu (Brent Hobbs) (05/03/90)
Oh well, just when the traffic on this thread was beginning to die down... 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. > A direct-mapped cache is easily built. You'll need some fast cache tag rams > plus the cache memory itself and three pals. This has been done for the > Atari ST for a while. Would you care to post the design for such a beast? BTW, where are you getting your performance figures? Anyone out there done this? > -- > 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." -- ____________________________________________________________________ | Brent Hobbs -- internet: brent@asparagine.phri.nyu.edu | |My employers know nothing about my postings, | |so I can say anything I want with no disclaimer! |
p554mve@mpirbn.UUCP (Michael van Elst) (05/03/90)
In article <BRENT.90May2143407@asparagine.phri.nyu.edu> 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. >Would you care to post the design for such a beast? BTW, where are >you getting your performance figures? Anyone out there done this? The design is published in the german magazine 'ST Computer' from 'Markt&Technik'. It has been tested with some calculation intensive programs: a raytracer, a mandelbrot generator and a DTP program called 'Calamus'. -- 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."
grr@cbmvax.commodore.com (George Robbins) (05/09/90)
In article <948@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes: > In article <BRENT.90May2143407@asparagine.phri.nyu.edu> 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... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
p554mve@mpirbn.UUCP (Michael van Elst) (05/10/90)
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.90May2143407@asparagine.phri.nyu.edu> 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."