Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!zs01+ From: zs01+@andrew.cmu.edu (Zalman Stern) Newsgroups: comp.arch Subject: Re: Instruction caches and closures Message-ID: Date: 2 Jul 90 08:46:31 GMT References: <771.267e5501@waikato.ac.nz>, <39466@mips.mips.COM> Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA Lines: 29 In-Reply-To: <39466@mips.mips.COM> The main problem with unsynchronized split I&D caches is the lack of efficient software support for flushing the caches and synchronizing them. For example, the MIPS cachectl system call requires one to invalidate at least an entire page. That artificially inflates the cost of leaving cache consistency out of the architecture for many cases. (Not to mention the overhead of the system call to begin with.) Perhaps this is why John suggests using a large chunk of memory and only flushing it when part of it is reused. A better example is the IBM RIOS which includes user level instructions for cache flushing and synchronization. The flush instruction takes a virtual address and flushes the cache line containing that address. (If the line is not present, then it does nothing). The cache flush instruction is also setup so that it can be efficiently used in a loop. One still has to pay the overhead of going through main memory on the RIOS. In addition to the the data cache writes to memory (the RIOS uses write back), there will be I cache misses when the written instructions are executed. The I cache misses may not come to many cycles though. In theory this could be avoided by providing some explicit mechanism to forward data from the data cache to the instruction cache. This isn't so unreasonable to contemplate on the RIOS in that I cache reload goes through the D cache chips anyway. (My understanding is that this was done for lack of hardware resources and is not good for performance.) Sincerely, Zalman Stern | Internet: zs01+@andrew.cmu.edu | Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890 *** Friends don't let friends program in C++ ***