Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!lloyd!cprice From: cprice@mips.COM (Charlie Price) Newsgroups: comp.arch Subject: Re: Icache flushes, self-modifying code and multiprocessors Message-ID: <44385@mips.mips.COM> Date: 28 Dec 90 22:53:36 GMT References: <1990Dec18.150615.26762@dg-rtp.dg.com> Sender: news@mips.COM Reply-To: cprice@mips.COM (Charlie Price) Organization: MIPS Computer Systems, Inc. Lines: 29 In article rouellet@crhc.uiuc.edu (Roland G. Ouellette) writes: > >Actually the cache flush function is trival... it is one monster >driver and a few gates per valid bit on the icache. There's no real >need to trap to the OS, microcode, whatever ... at least for a VLSI >cache tag store. This identifies one of the problems with providing an invalidate_the_entire_cache operation -- you need to be able to write a whole bunch of bits at one time. Even if that can be done in custom parts or on-chip, if you ever hope to build a system that uses more-or-less-standard SRAMs for the cache (regarded as a "Good Thing" here at MIPS) then it is probably a mistake to put such a feature into your architecture. Entirely aside from the implementability of the feature, I think you would want to examine how programs actually modified-or-created code in the data space and then executed it. Tossing the entire contents of the I-cache and refilling the useful lines can be a costly proposition. Unless incremental compiler systems or other users of the feature create a whole lot of code in between synchronization calls, they could easily be faster if they selectively invalidate a range of addresses via user-level instructions or an OS call. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA 94086-23650