Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!snorkelwacker!ai-lab!zurich.ai.mit.edu!jinx From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas) Newsgroups: comp.sys.hp Subject: Re: HP 9000/400 question Message-ID: Date: 14 Aug 90 16:23:40 GMT References: <7370192@hpfcso.HP.COM> Sender: news@wheaties.ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 37 In-reply-to: wayne@dsndata.uucp's message of 12 Aug 90 19:02:09 GMT In article wayne@dsndata.uucp (Wayne Schlitt) writes: pardon my ignorance, but why does the 040 break things worse than the 030? dont they both have separate instruction and data caches? the only difference that i know of is the fact the the 030's caches are tiny (256 bytes for I & D) and therefor you are not as likely to encounter problems. Certainly the probabilities are different, but there are real differences as well: - The 68030 caches are direct-mapped, while the 68040 caches are set-associative with random line replacement. - The 68030 D-cache is write-through, while the 68040 is either write-through or store-in, depending on the configuration (per access). With a 68030, main memory (or a secondary shared off-chip cache) always contains valid data, and if there is an i-cache miss, the right data will be brought in. Thus we only need to figure out a way (from user code) to flush the appropriate cache entry. Since the cache is direct mapped, executing a nop (or set of nops) with the correct bottom bits in its address will do the trick. If code modifications are rare, and a hundred instructions are not a large price to pay (as at the end of a relocating garbage collection), running through enough nops to "invalidate" all i-cache entries will flush the complete i-cache. The 68040 is worse. If the access is such that writes are stored in rather than written back, main memory does not have valid data. Thus even if we could invalidate the i-cache entries, we might get invalid data on the next access. Because the cache is set associative and the line replacement algorithm is random, we can't be sure that we've flushed the dirty data back to main memory or that we've invalidated the i-cache entry!