Newsgroups: comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Caches
Message-ID: <1989Jun22.160042.7604@utzoo.uucp>
Organization: U of Toronto Zoology
References: <799@acorn.co.uk> <95@altos86.Altos.COM> <41770@bbn.COM> <25114@shemp.CS.UCLA.EDU>
Date: Thu, 22 Jun 89 16:00:42 GMT

In article <25114@shemp.CS.UCLA.EDU> frazier@cs.ucla.edu (Greg Frazier) writes:
>>Looking at the RISC trend, it seems natural to assume that the next
>>step is to have a writeback cache with no "snooping" (as it has been
>>called) for either I/O reads OR writes, and solve the problem in
>>software.
>
>... the RISC philosophy would only put the
>cache consistancy functions in software if that made the system
>faster.  The basic idea of RISC is hardware minimization -> speed,
>not hardware minimization for the sake of minimization...

Making things easier to build generally makes them faster, because more
effort can be invested in making them fast and there are fewer constraints
that have to be observed.  It is verifiably true that unsnoopy caches are
easier to build than snoopy ones.  The real question is, how much penalty
is incurred by dealing with the issue in software, and do the benefits
exceed the costs?  If you read the IBM 360/370 Principles of Operations
book, you will find elaborate wording defining what you can and cannot
get away with in self-modifying instruction sequences.  The consensus
today is that it is better not to try to solve that problem in hardware,
i.e. that snoopy instruction prefetchers are not worthwhile.  Which way
the tradeoff goes for caches, I'm not sure.
-- 
NASA is to spaceflight as the  |     Henry Spencer at U of Toronto Zoology
US government is to freedom.   | uunet!attcan!utzoo!henry henry@zoo.toronto.edu