[atomchild411]

cpu: decode the R10000's cache algorithms from its own table

The R10000 is MIPS IV, so decode_cache_attr read Config.K0 (and the TLB's C field) with the VR5000's table, where 4 and 5 are reserved and decode as uncached. On the R10000 they are the coherent cacheable algorithms (R10000 User's Manual, Table 4-1). An OS that runs KSEG0 with K0 = 5, as IRIX on the O2 does, had every kernel fetch, load and store sent uncached to the bus.

The change

decode_cache_attr takes the R10000's table when C::R10K_CACHE_OPS:

• 3: cacheable;
• 4 and 5: cacheable coherent;
• 2 and 7: uncached (7, uncached accelerated, only gathers stores; a load is a plain uncached one);
• 0, 1 and 6: reserved, uncached.

Effect on the IP28

None for IRIX: it runs KSEG0 with K0 = 3 (Config reads 0x6c01a003), which both tables decode as cacheable. On an emulated IP28 the change is only visible to a guest that picks 4 or 5.

Tests

• Unit test: test_decode_cache_attr_matches_the_r10000_table checks all eight algorithms against Table 4-1; the existing R4400 and VR5000 table tests still pass.
• cargo test --lib: all pass, apart from breakpoints_can_be_set_while_running_and_report_their_hit and udp_fragmented_both_ways, which fail the same way on main here. Built in the three CI configurations.
• Booted an Indigo2 IP28 (Solid IMPACT) windowed: hinv, a disk read and write, the CD, audio, network, X, a keyboard login, a clean shutdown.
• cpubench on that IP28, interleaved with main over two rounds: the same 13.6 s total, every test within run-to-run noise (as expected with K0 = 3).

🤖 Generated with Claude Code