yupferris
Uncertainty when reading RegConfig register
The kseg0_cache_enabled value is ambiguous when reading the RegConfig register.
There are many combinations of three bits that cause the bool to be false, but the bool type is not descriptive enough to tell which of these combinations has actually been stored in the RegConfig register, when the program wants to read it.
In addition, there are several other bits of RegConfig that aren't being handled whatsoever, which is obviously going to be a problem when reading.
I don't know if any code ever actually reads from the RegConfig register, but this will be a problem if some code does.
I'm sorry for being zealous and making an issue for this, which might be an overreaction. I'm watching the series for the first time, and I noticed this problem just now. Just wanted to make sure this is properly addressed in orderly fashion.
There are many combinations of three bits that cause the bool to be false, but the bool type is not descriptive enough to tell which of these combinations has actually been stored in the RegConfig register, when the program wants to read it.
This is definitely true; I might make that a backing i32 or something. But are all of these combinations valid? Can you point to where I can learn more about why these combinations exist and what they mean?
In addition, there are several other bits of RegConfig that aren't being handled whatsoever, which is obviously going to be a problem when reading.
Pretty sure I deferred this specifically because we weren't reading any of these values yet :)
Can you point to where I can learn more about why these combinations exist and what they mean?
I don't know why the other combinations exist, but the datasheet explicitly shows what each combination means in Table 5-6, page 145 (Which is referred to by the description of the Config Register, page 153). Why they decided it needed 3 bits to describe this is beyond my understanding.
Pretty sure I deferred this specifically because we weren't reading any of these values yet :)
That makes sense. I must have missed it, my bad!
Table 5-6, page 145 (Which is referred to by the description of the Config Register, page 153)
Right, I'll keep this issue open as either a reminder to change this when we get to reading the reg, or if someone wants to fix the backing store and do a PR I'm cool with that as well.
I don't know why the other combinations exist, but the datasheet explicitly shows what each combination means in Table 5-6, page 145 (Which is referred to by the description of the Config Register, page 153). Why they decided it needed 3 bits to describe this is beyond my understanding.
There are 3 bits so that implementation specific caching modes can be used (such as Write Through mode). An implementation must have support for at least CCA (Cache Coherency Attribute) 2 and 3, although I don't think that the N64's CPU implements any more.
cool, thanks for the info :) I'm ignoring cache altogether for now; I have a feeling that's going to be ok for quite some time. In the future though as we hone in on the accuracy of the emu this is going to be awesome information to have, so thanks again :)
Yes, CCA ("cache coherency attribute") can be thought of as a selection of the "cache algorithm" to be used during memory accesses to that page. In particular, a value of 2 means "uncached" and 3 means "cacheable uncoherent". These are the only ones required to be implemented, and any other value depends on the processor implementation, so you'd have to check the programmer's guide to know the real meaning.
"See MIPS Run" chapter 6.2 p. 137 talks about this topic in passing.
The following chart comes from the official MIPS32 Architecture reference book, "MIPS32™ Architecture For Programmers Volume III: The MIPS32™ Privileged Resource Architecture":
From what I can gather, N64's CPU only implements the 2 required CCAs (and everything else is equivalent to "Cacheable")
However, to make it clear why there are 3 bits, you can take a look at interAptiv's documentation as an example of a MIPS32 processor from 2016:
