> 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
> 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.
Indeed, Linux could need a little polish in that respect ...
> 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.
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 ...