gnu@l5.uucp (John Gilmore) (09/20/85)
In article <69@intelca.UUCP>, kds@intelca.UUCP (Ken Shoemaker) writes: > If you have the processor in a polling loop, and you > know that either to get out of the loop you'll get a memory fault on a > write, and the status of that fault will be returned in a register by the > bus fault handler, you have to be very careful... He's right; you have to be very careful. This is a highly processor-dependent operation. Can you run the same code (and fault handler) on an 8086 and an 80286 and an 80386? (You can't on 68000, 68010, and 68020.) You're going to have to change a few things to upgrade to a new chip (anywhere in a system, not just the CPU). The idea is to make the changes only affect the kernel hackers, leaving the user code running compatibly. A kernel hacker experienced in porting would probably not write a loop that only exits when it gets a bus error, by passing funny values back in registers -- or s/he would expect it to break during a port. A good hardware designer would not design hardware that ends a polling loop by giving a bus error when it has no data. I believe the way Unix handles such things is by having a global variable ("lofault") that gives a place to jump to when a bus error occurs. When we want to test accessability of a virtual address, we set that to point to a routine that returns a "bad address" value. The main routine just makes the access and returns the "good address" value. We never have to try to resume the code that was running at the time of the bus error; we just run alternate code. There are still possible problems here, and this is an area that needs looking at when porting to new processors, like most of the MMU-related code. > The easy way out is just to not allow concurrent data > accesses to the internal data cache while there are outstanding requests > on the external bus. This sounds like a possible bottleneck; what does it really buy you in practical operation? It lets you avoid carefully reading your bus error handling code? I'd trade a careful read for a 3% performance increase... > But thinking about debuggers, doesn't > this little 68020 feature cause problems if you want to trap > on a write to memory (ala an ICE unit?) I recall a sentence in the IBM 370 "Program Event Recording" section of the manuals. (PER is a facility that gives access to breakpoint style hardware.) It was something on the order of "turning this on makes the machine run a lot slower". The 68020 provides ways for an ICE to turn off the internal cache and to single step or single-instruction the processor, as well as insert breakpoints. These ways almost all involve slowing down the processor so the ICE can see what it is doing. I'm happy to run in "fast mode" 99% of the time and run in "debug mode" the rest.