Re: CVS commit: src/sys/arch/m68k/m68k

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> 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