Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!olivea!apple!mips!lloyd!cprice
From: cprice@mips.COM (Charlie Price)
Newsgroups: comp.arch
Subject: Re: 64bits: Area Overhead and Opportunity Costs
Message-ID: <46131@mips.mips.COM>
Date: 23 Feb 91 20:48:35 GMT
References: <7967@exodus.Eng.Sun.COM> <757@ajpo.sei.cmu.edu>
Sender: news@mips.COM
Reply-To: cprice@mips.COM (Charlie Price)
Organization: MIPS Computer Systems, Inc
Lines: 34

In article <757@ajpo.sei.cmu.edu> carter%csvax.decnet@mdcgwy.mdc.com writes:
>In article <7967@exodus.Eng.Sun.COM> rtrauben@cortex.Eng.Sun.COM (Richard Trauben) writes:
>Also ...
>>Let 1/3 of the area budget be on-chip cache, 1/3 floating point unit and
>>1/3 be integer unit. A move to 64bits will have virtually no impact on
>>the fp engine. While the area for tags double, large data block caches 
>>(i.e. 32-64bytes/tag) make this increase in tag ram area neglectable.

>Tag size only doubles if you have virtual-address caches, otherwise tag size
>depends on physical address size (I doubt the R4000 has a 64-bit physical
>address :) 
>Still, I worry about this for those design points where you want/need a
>virtual address cache, where the design point would otherwise be a shorter
>line (a branch target cache would be an excellent example, if someone starts
>wanting 64-bit instruction addresses for some reason (e.g. shared library 
>tricks) - small on-chip caches in lower density processes like GaAs 
>constitue a less contrived example).

What you say is right.

Just to keep the confusion factor down here,
the on-chip primary caches in the R4000 are

 virtual index		(access is based on the virtual address)

but

 physical tag		(deciding on a hit/miss is based on the phys addr)

You overlap the virtual-to-physical translation with the cache access.
The secondary cache is physical/physical.
-- 
Charlie Price    cprice@mips.mips.com        (408) 720-1700
MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA   94086-23650


Brought to you by Super Global Mega Corp .com