Path: utzoo!attcan!uunet!van-bc!mdivax1 From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga Subject: Re: GVP 68030 reviewed in Sentry Message-ID: <2468@van-bc.UUCP> Date: 12 Jun 89 13:40:41 GMT Sender: usenet@van-bc.UUCP Lines: 36 In <11044@mcdphx.phx.mcd.mot.com>, dbk@teroach.UUCP (Dave Kinzer) writes: > Unfortunately, I have been known to load a program or two in my usage of >my Amiga. If the program is transfered using DMA, there is a possibility >of stale data in the instruction cache. The 68030 cache is not exactly >a Most Recently Used cache, some stale data can exist even after thousands >of instructions have been executed (though not likely [read infrequent guru]). Good point. I hadn't thought about the problem in terms of size of cache, figuring that by the time another program got loaded, there wouldn't be any trace of the old contents lying around in the cache. > I seem to recall a flush cache system call, but I could not find it in >about 2 minutes of looking. If it does not exist, it needs to (can you say >1.4 wish? I knew you could.) It perhaps should be implemented as something >external to the system (Romtags?), so as new processors become available >it can be easily changed (Also changable for aftermarket cache boards should >they become available.) I can't find it either. You may have been thinking of CMD_FLUSH for IO, or FlushCList, which are the only references to 'flush' I can find in autodocs. > Any task that is in control of DMA (say, the trackdisk device) would call >this routine after the DMA is finished. The routine would flush the cache >if it exists. Wouldn't it have to call for a flush before IO started? -larry -- Van Roy's Law: An unbreakable toy is useful for breaking other toys. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+