>> If Philips/Tosh are really aliasing the PrID of the R4650, sombody
>> has done something Deeply Evil (and probably in violation of one
>> agreement or another). I'm checking with MIPS HQ on this, and
>> hoping that in fact the R4650 value in the source code is in error.
>The R3900 should be 34 (decimal). We don't have a record of the
>R4640/4650, which must surely be the same as each other.
The collision is real. As has been noted elsewhere in this thread,
the R4640/4650 has no business running Linux, as it lacks a
page-based MMU. I had a bit of "cognative dissonance" when
I did the conversion to the C-based system, but I left it in, figuring
it was better to preserve partial support than to eliminate all trace
of it. But I think it could be argued that the R3900 characteristics
should go into the table in place of those for the R4650 (which
are anyway wrong bacause they indicate that there is a TLB).
Those characteristics should be essentially the same as those
for the R3000A.
>Probably not. But this is a good chance to ride a favourite hobby
>But I think code should *never* read the PRId value.
>It often doesn't change when the chip does, and often changes when the
>chip doesn't. There's no guarantee that it marks the difference you
>care about, and if it does now there's no guarantee it will do so
>tomorrow. Chip companies change it (or don't) for marketing reasons
>more often than technical ones.
>Instead, software should contain probes for individual attributes.
>Want to know whether you've got an R4000-style CP0? Read the 'count'
>register and see is it counting. Want to know how large the cache is?
>Easy to look for wraparound on an R3000; on an R4000, if you can't be
>bothered to do the rather elaborate code, use the Config register.
>Want to know whether the cache is 2-way set associative? It usually
>doesn't matter, so remain in happy ignorance. How big is the TLB?
>read and write to it and see when it wraps. And so on.
>[Nobody will listen, probably rightly - I don't seem to have time to
> hack code any more...]
I quite sympthise with your frustration, and indeed the sloppy
use of PrID by various MIPS licensees makes it impossible
to use *only* the PrID to determine things like cache size. That
having been said, I don't see it as being practical to dynamically
probe for, say, the CP0 hazards to be respected in the TLB miss
handler. Probing for the TLB size may not be as simple as you
think: there's nothing that says that access to index N+1 is going
to *necessarily* wrap to 0 - that's an implementation detail.
Similarly, testing for the presence or absence of an FPU
*might* be as simple as setting the CU1 bit and seeing if
it can be read back, but I'm aware of at least one MIPS-based
design where there's a flip-flop there even without an FPU.
Sometimes one *does* care about the associativity of a
cache, as in the case where one wants to flush all possible
virtual aliases of an address. Etc, etc.
The PrID has been horribly abused, and can not be treated as
if it were a true architectural mechanism for distinguishing
implementations, but it remains at minimum one of the tools
available to the OS to determine where it is running. With the
newer MIPS32 and MIPS64 CPUs, we have codified mechanisms
for determining most of the information in the mips_cpu structure
based on extended configuration information from the core. Most
of the MIPS licensees have agreed to use this system for future
designs. But so long as Linux is going to be used on older CPUs,
which will be for a while, I fear we will be stuck with a mixture of
PrID and heuristics.
Kevin D. Kissell
MIPS Technologies European Architecture Lab