Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!xavax!alvitar
From: alvitar@xavax.com (Phillip Harbison)
Newsgroups: comp.arch
Subject: Re: Instruction caches and closures
Message-ID: <1990Jul7.041100.2413@xavax.com>
Date: 7 Jul 90 04:11:00 GMT
Followup-To: comp.arch
Organization: Xavax
Lines: 30

In article <1756@charon.cwi.nl> jack@cwi.nl (Jack Jansen) writes:
> This I/D cache discussion sparked a thought: I get the impression that
> separate I/D caches are used mainly to get the benefit of two-way
> set associative caches without the cost involved. If there aren't any
> other added advantages, why not just have two caches ...

This is not the reason for split I&D caches.  If you think about it,
the split I&D caches require about as much hardware as any two-way
set associative cache (two sets of comparators, two sets of tag RAMS,
two data paths, two bus connections, etc.).  There appears to be two
major reasons for using a split I&D cache.  [1] It allows the CPU to
implement a Harvard architecture and enjoy the associated benefits,
i.e. twice as much memory bandwidth.  [2] It allows each cache to be
tuned for performing a task.  For example, large cache block sizes
may be very beneficial in an I-cache but less useful in a D-cache.
Also, the I-cache doesn't have to be writeable by the CPU.

> ... instructions and data, and steal the top address bit to denote
> which cache to use? The OS can easily set things up so that text
> segments are mapped in with the top bit clear, and data segments
> with the top bit set.

If you design a cache in this manner, it is not a 2-way set associative
cache as your previous comments imply.  In fact, it is just a direct-
mapped cache that is twice as large.

-- 
Live: Phil Harbison, Xavax, P.O. Box 7413, Huntsville, AL 35807
Uucp: alvitar@xavax.com
Bell: 205-883-4233, 205-880-8951