Ronald G Minnich rminnich@lanl.gov writes:
Neil has a very interesting point, and it does bring up the "cache as ram" issue again.
Neil, my only question is, did you test this MTRR approach on lots of CPUs. My impression is that it is not guaranteed to work.
Let me respond. My apologies for the delay but I misplaced this email.
There are several sides to this problem. 1) I have tried setting up the MTRRs and fake an area of ram. In fact if you look at the p4dc6 I actually implemented it and did a port that way.
Unfortunately there is not an architecturally garanteed way to make this work, and cpu designers are continuously tweaking how their caches work so it breaks with new cpus at the drop of a hat. Especially new hyperthreaded monsters.
There is no real savings in having code that breaks when new cpus are introduced.
2) Using memory that is elsewhere in the system. I do use cmos memory but not currently for temporaries. I like the idea. But with only 128bytes to play with you can not do much with it.
3) Using external ram for a stack, is dangerous in a couple of ways. Cache coherency with pci devices isn't garanteed, so setting up mttrs over the stack is not guaranteed to work.
The common case is in processors is to work against cacheable memory. I have seen P4's incorrectly execute code when caching was disabled. Stacks may soon follow suite. So long term this does not look a solution.
Then there is the added danger that the device or something on the path to the device will be corrupted/broken. And then you get very strange hard to debug failure cases.
The only real solution to this problem is to build a compiler that generates code that does not use ram. And then the compiler can have all of the smarts about how to call subroutines etc. The coding would still be tryi
Eric