> 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.
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...]