On Thu, 3 Apr 2003, Ralf Baechle wrote: > > 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 ... Hmm, that's even more interesting -- how can instruction fetches be distinguished from data reads externally??? Then again, the memory controller shouldn't be able to observe inter-cache data moves. Strange. > Maybe DECstation and other SGI hardware got that better? No problem testing, I suppose. > > 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. This can be benchmarked -- there may be some gain for p-cache flushes indeed. > > > 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. I was referring to testing cache and VCE code specifically -- you won't get that from usual evaluation boards. Note that with evil /dev/mem maps you should still be able to force VCEs if needed. ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
