Hello ! On Tue, 10 Aug 2004, Kumba wrote: > > Date: Tue, 10 Aug 2004 04:30:00 -0400 > > From: Kumba > > To: Peter Fuerst > > Subject: Re: IP28 Patch > > > > ... > > Also, I've written to two of the mips gcc maintainers regarding the > > cache barrier support, and the response does not bode well for adding > > cache barriers to gcc. He described the ideas SGI references in the > > R10000 User manual as being "horrifying", but said he will try to > > contact the two NetBSD guys who've done alot of research into the issue > > to see if they came up with anymore ideas. > > ... Yes, horrifying they are, the "Workarounds for Noncoherent Cached Systems" from the R10000 User's Manual. IMHO it would be best, to ignore these, and just put appropriate cache barriers at the entry of each basic block, that contains stores to memory other than stack, as they did it in IRIX. (discussed in http://mail-index.netbsd.org/port-sgimips/2000/06/29/0006.html) I would do this, but as i mentioned, it would take some time to get familiar with the gcc source, while - as i guess - a gcc maintainer might accomplish it between lunch and coffee ;-) For the changes we must 1) Identify stores to the specified memory in RTL. 2) Decide, when to put the cache barrier: - When the basic block is created, optimizing it away afterwards, if not needed. - After most optimizations (as i saw, basic block information is still available in final.c), regarding possible side effects of lately inserted instructions. 3) Something i didn't think of... ;-) On the other we got quite far with the already taken measures (putting dma memory to save places, appropriate cache flushes, reserving the boundary page, ...) without compiler support. with kind regards pf