Subject: Magnum 4000 caches

From: Ralf Baechle <[email-masked]>
Date: Thu, 23 Oct 1997 19:05:10 +0200 (MEST)

Hi,

maybe one of the old Mips people can answer me two questions:

 - why do the Magnum 4000PC instruction and data caches have a different
   linesize for the L1 caches, but the Magnum 4000SC not?
 - does the Magnum 4000SC use a split instruction/data L2 cache?

TIA,

  Ralf

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 23 Oct 1997 10:21:41 -0700

>    linesize for the L1 caches, but the Magnum 4000SC not?

     It turned out that, at least for some workloads, the 4000PC
worked better that way.  (If I remember correctly, a 32-byte linesize
is better for the icache, since a 4-instruction basic block is
unusual.)  However, not all boxes use the same linesize values,
because there were hardware bugs with at least some of the memory
controllers which were affected by the choice of linesize.  I don't
remember the details anymore, although I might find them in my mail
archivies.  I have a 4000PC system (32-byte I, 16-byte D, MCT version 3)
and two 4000SC systems (16-byte I, D, and S, MCT version 2) still online.
I think that MCT version 2 would not support a 32-byte line.
 
 >  - does the Magnum 4000SC use a split instruction/data L2 cache?

     No, it has a unified writeback L2 cache.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 23 Oct 1997 19:56:06 +0200 (MEST)

> I think that MCT version 2 would not support a 32-byte line.

So as the easy solution, as I understand things we should be safe by
just leaving the linesize as the firmware chooses them for us Magnums?  
I actually intended to experiment with the linesize on R4k but as
things look now this isn't a good thing.

Btw, seems we'll get an interesting new target for Linux.  It's currently
ftp.uni-erlangen.de and one of the admins who might do the job, a Linux/68k
hacker told me it's a 3 x R6000 box with 256mb of RAM currently running
ES/IX something like that ...

  Ralf

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 23 Oct 1997 11:08:31 -0700

> things look now this isn't a good thing.

     Yes, I think you should leave the linesize alone, at least on
the MCT version 2.  You could try alternate linesize values on the MCT
version 3.  The cache control code should use the linesize values from
$config.  By the way, I have found that it is generally faster on the R4000 (and
especially on later processors) to compute such values from $config each
time than to load them from variables in memory.  The amortized cost
of the extra cache misses can easily outweigh the extra instructions needed
to recompute the value (since the latter are really very few, if you
code the sequence cleverly in assembly language).  Similarly, if you need
to test for processor type, it is usually faster to fetch and decode
$prid than to use a variable in memory.

 > ES/IX something like that ...

       The R6000 is a real challenge.  It is substantially different
from the R3000 and R4000.  In particular, it uses part of the cache
as a sort of second level TLB.  ES/IX is the CDC version of MP RISC/os.
(MIPS worked on MP RISC/os, but never shipped it to customers; CDC took
it over as a product.)  The I/O is fairly straightforward, being mostly
VME devices, but it does include I/O address mapping hardware which must
be configured.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 23 Oct 1997 20:23:38 +0200 (MEST)

> $prid than to use a variable in memory.

Indeed, Linux could need a little polish in that respect ...

> VME devices, but it does include I/O address mapping hardware which must

Is the information in newer releases of Kane's MIPS bible sufficient to
do the R6000 part of the job?  I guess the company (BIT ???) that made the
R6000 is no longer around, so it would make sense if Roman'd ask them
for a manual ...

  Ralf

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 23 Oct 1997 11:47:43 -0700

Ralf Baechle writes:
...
 > R6000 is no longer around, so it would make sense if Roman'd ask them

     BIT made the parts originally, but we later got the parts from NEC.
The latter were faster, more reliable, and much cheaper.  CDC might still
provide the manuals.  As far as I know, the R6000 is not well documented
in the regular MIPS documentation.  I might, however, be able to get you
some information about processor issues.