From owner-riscy@pyramid.com  Tue Aug 10 04:48:07 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA19719; Tue, 10 Aug 93 04:48:07 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28292; Tue, 10 Aug 93 01:47:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08392; Tue, 10 Aug 93 01:46:26 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA08384; Tue, 10 Aug 93 01:46:24 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28237; Tue, 10 Aug 93 01:47:21 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA16911
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 02:46:08 -0600
Message-Id: <199308100846.AA16911@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: R4xxx Cache size, pedantic ramblings
In-Reply-To: Your message of "Tue, 10 Aug 1993 09:00:03 +0200."
             <9308100700.AA22443@erasmus.et.tudelft.nl> 
Date: Tue, 10 Aug 1993 02:46:06 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    >
    >R4000 : 8K I, 8K D
    >R4400 : 16K I, 16K D
    >
    >The maximum imposed by the R4000 architecture is 32K each for the primary
    >cache.  I don't know about the 4200 since I don't have a data book in fron
   t
    >of me like I do for the NEC Vr4000 and Vr4400, PC, SC, and MC variants :-)
        
    Huh? Does that mean that the ARCHITECTURE defines a maximum CACHE size?

    According to current definitions here at the computer architecture group,
    cache size is an implementation aspect, and shouldn't be visible at the
    architectural level.

Other people or groups, have different definitions.  Many software 
people consider architecture to be a given combination of machine,
cpu, and operating system.  Some vendors consider it to be their
register and instruction set definitions, including bit fields
(BTW, if this were the case the limit would have been stated as
512K each for the primary caches), others consider it to be their 
implementation (NEC's data book seems to use this definition since 
it's not using one of the others)


According to 

_MIPS R4000 USER'S MANUAL_

by Joseph Heinrich

which happens to be what NEC is calling their 

VR4000-SERIES(tm)ARCHITECTURE
		 ^^^^^^^^^^^^
INCLUDING VR4400(tm)
USER'S MANUAL

under the "Processor General Features" heading of page 6 

"Cache Control,  The R4000 primary instruction and data caches reside on-chip, 
and can each hold 8K bytes.  In the R4400 processor, the primary caches can 
each hold 16K bytes.  Architecturally, each primary cache can be increased to
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hold up to 32K bytes.  An off-chip secondary cache (R4000SC and R4000MC
^^^^^^^^^^^^^^^^^^^^
processors only) can hold from 128 Kbytes  to 4 Mbytes.  All processor
cache control logic, including the secondary cache control logic, is on
chip"

Their usage of "architecture" seems to indicate a usage refering 
to their implementation as perfectly acceptable.  What does it matter?  As 
long as the chip does what we want, I don't care what their definition of 
architecture is.

    -----
    This means that the R4xxx has a bad design: the design mixes implementation
    
    with architectural features. The R4000 isn't as clean as we thought. This
    means that we can't use the R4000 as the processor.... :-)

    -----

For those who care about the facts and not what definition of "architecture"
was used,  here are a few interesting factoids that would affect relative 
cache hit rates of an i486 (baseline) and our system...

1.  Primary I/D caches are separate.

2.  The 4000PC has 8K I/D caches, the biggest R4000 series chips SHIPPING have 
	16K I/D caches.

3.  The caches are direct mapped.

4.  Line size is user-configurable to either 16 or 32 bytes wide.

5.  The data cache can be write-back.

6.  All instructions are 32 bits.

Compare to the i486 if you want : 

1.  There is a single cache.

2.  The i486 has an 8K cache.

3.  The primary cache is set associative (I think  4-way).

4.  Primary cache line size is 16 bytes

5.  The primary cache is write-through.

6.  Some instructions are one byte, many are two-byte, 16 bit 
	accesses require a prefix in a 32 bit mode task, 
	other things require prefixes.

 
From owner-riscy@pyramid.com  Tue Aug 10 05:16:10 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20362; Tue, 10 Aug 93 05:16:10 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA01197; Tue, 10 Aug 93 02:12:30 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12586; Tue, 10 Aug 93 02:10:28 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA12575; Tue, 10 Aug 93 02:10:25 -0700
Received: from liberator.et.tudelft.nl 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA00947; Tue, 10 Aug 93 02:11:21 -0700
Received: by liberator.et.tudelft.nl (4.1/1.34JP)
          id AA09361; Tue, 10 Aug 93 11:08:48 +0200
Date: Tue, 10 Aug 93 11:08:48 +0200
From: wolff@liberator.et.tudelft.nl (Rogier Wolff)
Message-Id: <9308100908.AA09361@liberator.et.tudelft.nl>
To: 1@liberator.et.tudelft.nl, 11@liberator.et.tudelft.nl, riscy@pyramid.com
Subject: Re: R4xxx Cache size, pedantic ramblings
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

	According to 

	_MIPS R4000 USER'S MANUAL_

	by Joseph Heinrich

	which happens to be what NEC is calling their 

	VR4000-SERIES(tm)ARCHITECTURE
			 ^^^^^^^^^^^^
	INCLUDING VR4400(tm)
	USER'S MANUAL

This agrees with "our" definition of architecture: architecture is
what the user will see of a processor. The cache size should be 
more or less transparent. A specialized timing program might figure
it out, the user manual might mention that the current chips have
a such-and-such cache size, but users shouldn't be able to poke
around at the cache such that they need to be aware of the cache
size. 

It seems that the R4xxxx designers found a reason
that requires the OS or the Users access to (part of) the cache,
and have limited an address field to 15 bits. This isn't really critical.

The '486 has : 

	1.  There is a single cache.
	2.  The i486 has an 8K cache.
	3.  The primary cache is set associative (I think  4-way).
	4.  Primary cache line size is 16 bytes
	5.  The primary cache is write-through.

Compare to R4000:
	1.  Primary I/D caches are separate.
This is an advantage: If one of the caches starts thrashing, the other
might still function properly. Thrashing is when a cache is completely
uneffective, because the program almost never references an element in
the cache.
	2.  The 4000PC has 8K I/D caches, the biggest R4000 series chips 
		SHIPPING have 16K I/D caches.
Ok. Larger caches are better.
	3.  The caches are direct mapped.
This is an disadvantage. Set associative is better (but the difference 
might on the average be neglectable).
Lets assume a cache size of 4000 bytes. Both caches can cache elements
at address 0, 1000, 2000 and 3000 at the same time. However should
a program reference 0, 4000, 8000 and 16000 at the same time, the set
associative cache will be able to cache them all four, whereas the 
direct mapped cache can only hold one of them.
	4.  Line size is user-configurable to either 16 or 32 bytes wide.
Depending on the speed of the page-mode, having a larger line size
will be worse or better.
	5.  The data cache can be write-back.
Depending on the application this is an advantage. Fact is that OS's
can do very little to optimize the use of this bit. You run a benchmark,
decide which setting of the bit is best, and leave it that way.
(Intel probably did this before releasing the chip..... :-)
	6.  All instructions are 32 bits.
This has nothing to do with caches.


				Roger.

 
From owner-riscy@pyramid.com  Tue Aug 10 05:52:48 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA21474; Tue, 10 Aug 93 05:52:48 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04591; Tue, 10 Aug 93 02:52:49 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16782; Tue, 10 Aug 93 02:51:34 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16775; Tue, 10 Aug 93 02:51:31 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04543; Tue, 10 Aug 93 02:52:34 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA17424
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 03:51:25 -0600
Message-Id: <199308100951.AA17424@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: R4xxx Cache size, pedantic ramblings 
In-Reply-To: Your message of "Tue, 10 Aug 1993 11:08:48 +0200."
             <9308100908.AA09361@liberator.et.tudelft.nl> 
Date: Tue, 10 Aug 1993 03:51:24 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


--------

    Compare to R4000:
    	6.  All instructions are 32 bits.
    This has nothing to do with caches.

Indirectly, it does.

I should have been more specific here : specifically, I was 
getting at the lack of variable sized instructions forcing the 
instructions to be bigger (ie, 32 bits for the R4000 vs. 8,16, etc. 
for the i486) meaning the R4000 will have larger code and will 
therefore require a larger cache to maintain the same hit-rate.

I should have generalized more and said 

"RISC chips have bigger code than CISC chips, and therefore will
need larger caches to have the same hit rate"

--------

 
