Richard, On Monday 05 June 2006 12:06, Richard Earnshaw wrote: > I'm confident right now that these will be too invasive to include in > mainline.
As said before, this is OK for me. > The changes that tend to get incorporated into the compiler are to > work around bugs in the CPU, not bugs in some H/W developer's use of > the CPU. The former affect all users of the processor, the latter > only that one case. > > If we started putting in hacks for the latter the compiler back-ends > would become unmaintainable in almost no time at all. Agreed. > PS. Using swp is a bad idea IMO, this instruction is *very* slow on > some CPU implementations because of the way it interacts with caches. Yes, swp forces a cache load. But in this particular case, forcing a cache load is the ONLY way to circumvent the hardware problem. If there is a block write, cache loads are forced only each 32 byte accesses. Other possible solutions: a) code a 16bit read-modify-write. This will also cause a cache load, and will need much more code, because it will have to look at the LSB of the address to know where to insert the byte into the word. b) use the protection unit and make a data abort for a write to that memory region. This has the advantage of affecting ONLY the critical memory region (not all the other ones), but the disadvantages are big: all memory writes are affected, and a data abort handler is very slow. This solution was implemented before, it was 100 times slower than native access. Unusable. regards Wolfgang -- We're back to the times when men were men and wrote their own device drivers. (Linus Torvalds)
