rob@tolerant.UUCP (Rob Kleinschmidt) (08/31/89)
Nastiest 680x0 restart problem I can think of is the CAS2 instruction, which has two separate read-modify-write operands. Not quite sure how this would be handled with instruction restart. I spent several years fighting with Motorola mid-instruction faults, and as a consequence, am a big fan of instruction restart. Some of the nastier problems encountered included the following: Multi-processor. If you had two 680x0 chips with different microcode levels you could not switch processors on a bus error. Either you had to ensure that all processors in the system were the same rev level, or arrange to always run the faulted instruction on the processor where it occurred. We had a go around with Motorola on the 68010, where we found that the rev level of the processor could not always be reliably determined from the external markings on the chip. Unix signals. You cannot really process a unix signal with a bus error stack frame on the kernel stack. You had to figure out something to do about the bus error before you could modify the P.C. You could either try to save the processor state somewhere (user space ???) or trash the bus error, or run to an instruction boundary. We chose to either trash the bus error or recover and trace to an instruction boundary. I could not see leaving processor state in user space where it could be modified, and could not see a good solution in kernel space that allowed for both recursion and longjmp exits from signal handlers. Bourne shell. Early versions of Bourne shell assumed that they could catch a bus error, allocate bss space, and return to the faulted instruction. This did not work well with our trace/trash fix for unix signals. We hacked the shell to not do this and pressed on. 68881 floating point co-processor. This had the same problem with mid-instruction signal processing as bus error. This could occur on any interrupt, without any fault condition.