Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!comp.vuw.ac.nz!actrix!Bruce.Hoult From: Bruce.Hoult@bbs.actrix.gen.nz Newsgroups: comp.arch Subject: Re: I-cache flush for SMC (was: Re: m88200 cache flushes on DG Aviion) Message-ID: <1990Dec18.065125.6165@actrix.gen.nz> Date: 18 Dec 90 06:51:25 GMT References: <4322@photon.oakhill.UUCP> <738@ajpo.sei.cmu.edu> Sender: Bruce.Hoult@actrix.gen.nz (Bruce Hoult) Organization: Actrix Information Exchange, Wellington, New Zealand Lines: 20 Comment-To: carter%csvax.decnet@mdcgwy.mdc.com Scott Carter writes: >For processors with direct-mapped I-caches, a hack which is probably feasible, >if ugly, is to link in a code space section which consists of nothing but >return instructions, one per line, which covers all the classes in the I-cache. >e.g. on a Mips R3000 this wastes 64KB in the code image, and gives you an >Icache flush at the cost of seven instructions and one spurious I-cache miss >per line/block (icache refill block) per block you need to invalidate. Not >that bad, really. Why not use the same number of NOPs (or whatever harmless instruction reads most bytes of instruction stream in the fewest cycles -- for example on the 6502 something like LDA #0000 was 50% faster than NOPs). It'll be much quicker to execute. That's how some friends and I saved the cost of memory refresh hardware on a home-brew computer -- just get an interrupt routine to execute a page (256 bytes for the 64 Kbit chips we used at the time) of NOPs every few mS. This only used a few percent of the processor time. -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ