> I did it to be on the safe side. If the kernel was to be built with -mlcfix > passed to gas(1) the nop would be inserted.
It seems there might be some confusion between the goal (i.e. avoiding f-line exception during write-pending) and the approach/workaround (inserting a nop before F-line instructions), or between "what's necessary" and "what's sufficient". IMO "the safe side solution" should not be blindly applied unless there is no other sufficient countermeasure. > I'm unaware as to how many writes might be pending in the pipeline? If the technical rationale behind the implementation is not clear, it's advisable to survey the relevant documentation before proceeding. According to "1.4 FUNCTIONAL BLOCKS" chapter in M68040 User's Manual, 68040 has 6 instruction pipeline stage in the integer unit: 1) Instruction fetch 2) Decode 3) EA calculate 4) EA fetch 5) Execute 6) Write-back On the other hand, "A.5.1 Unimplemented Floating-Point Instructions and Exceptions" chapter also says: >> 1. When an unimplemented floating-point instruction is encountered, >> the instruction is partially decoded, and the effective address is >> calculated, if required. This implies the unimplemented FP insn exception will not be taken until "EA calculate" is complete. >> 2. The processor waits for all previous integer instructions, write-backs, >> and associated exception processing to complete before beginning >> exception processing for the unimplemented floating-point instruction. >> Any access error that occurs in completing the write-backs causes >> an access error exception, and the resulting stack frame indicates >> a pending unimplemented floating-point instruction exception. >> The access error exception handler then completes the write-backs >> in software, and exception processing for the unimplemented >> floating-point instruction exception begins immediately after >> return from the access error handler. This also implies the unimplemented FP insn exception will not be taken until the write-backs will be complete. However the 68LC040 E4 errata says (per PR/13078): https://gnats.netbsd.org/13078 >> E4- If a write is pending on the 68LC040 and an F-line Unimplemented >> Exception is taken, the pending write data may be lost. >> >> Workaround: place a NOP before the F-line instruction This implies there are some unexpected silicon delay etc. on the chip and the defect could trigger the exception processing before all necessary write-backs are complete. The described workaround requires "a NOP before the F-line instruction" so maybe we can assume only one instruction (without write-back) is enough to wait the unexpected delay that might cause lost of write data. In the fpu_probe() case, the fnop is in an explicit asm() statement so we can easily determine if there is a possible problematic instruction that requires write-back before the fnop. The answer is NO in this case (bit test and conditinal branch are enough). > But if you don't deem it necessary I'll remove it. When committing code, it's important to provide a obvious explanation of the technical rationale behind the implementation. Without such rationale, the code can become difficult to maintain in the future, as later contributors may not understand the reasoning behind key decisions. That's what isaki@ pointed out before. Thanks, --- Izumi Tsutsui
