On Thu, Apr 03, 2003 at 04:48:21PM +0200, Maciej W. Rozycki wrote: > > I know of one machine where changing the size of the cacheline is supposed > > not to work, that's the MIPS Magnum 4000 and it's close relatives. > > Hmm, why -- is such a change observable externally in any way? Of > course you can't switch the other way if the s-cache uses a line width of > 16 bytes. Maybe that's the case with the Magnum? It's a hardware problem with the memory controller I was told by one of it's developpers. That forced them to run the machine with an different line size for D-cache and I-Cache. There's various revs of the Magnum's memory controller and only one of them got all the cases right ... Maybe DECstation and other SGI hardware got that better? > > Anyway, I put the check there for the unlikely case there are broken > > systems out there. In practice I assume vendors were aware of this > > problem and the check is purely theoretical and for paranoid correctness's > > sake. > > Still V3.0 should be taken into account. Ok. > > It seems like changing the configuration to larger cache lines where > > possible should improve performance somewhat. If all the cache code is > > Why? It isn't that obvious especially as a p-cache miss costs a single > cycle only. During my recent work on the cache code I found the execution time of cache flushing code to be quite a bit higher than previously assumed so larger lines would help reducing that also. > > working truly correct we also should no longer see VCE exceptions on > > R4000SC processors - the reason why Indys are still a valuable test tool. > > As are DECstations which use the opposite endianness -- so you can test > code both ways. A bunch of evaluation boards that support running in the other endianess and way exceed the performance of any R4000-based platform. Just having to flip a switch on the board is very handy. Ralf
