Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!sdd.hp.com!mips!orac!hawkes From: hawkes@mips.COM (John Hawkes) Newsgroups: comp.arch Subject: Re: Instruction caches and closures Message-ID: <39838@mips.mips.COM> Date: 2 Jul 90 16:56:40 GMT References: <771.267e5501@waikato.ac.nz> <39466@mips.mips.COM> Sender: news@mips.COM Reply-To: hawkes@mips.COM (John Hawkes) Organization: Mips Computer Systems, Inc. Lines: 23 In article zs01+@andrew.cmu.edu (Zalman Stern) writes: >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. The MIPS 'cachectl' syscall flips a virtual address range from cached to uncached, and vice versa, and indeed it is implemented with a page-sized granularity. I suggest you instead consider 'cacheflush', which flushes/invalidates arbitrary sized pieces of the address space from the I-cache, D-cache, or both. Granted, this isn't as efficient as an inline user-executable instruction sequence, but it is more efficient than the sledgehammer approach of 'cachectl'. -- -- John Hawkes {ames,decwrl}!mips!hawkes OR hawkes@mips.com