On Fri, 21 Mar 2025, Marco Crivellari wrote: > > This instruction sequence still suffers from the coprocessor move delay > > hazard. How many times do I need to request to get it fixed (counting > > three so far)? > > Can I have more details about this? > > I can see it is the same code present also in local_irq_enable() > (arch_local_irq_enable()), Unlike `__r4k_wait' that code is not in a `.set noreorder' region and the assembler will therefore resolve the hazard by inserting a NOP where required by the architecture level requested (with `-march=...', etc.). Try compiling that function for a MIPS III configuration such as decstation_r4k_defconfig or just by hand with `-march=mips3' and see what machine code is produced. > and from the manual I've seen: > > "The Spacing column shown in Table 2.6 and Table 2.7 indicates the > number of unrelated instructions (such as NOPs or SSNOPs) that, > prior to the capabilities of Release 2, would need to be placed > between the producer and consumer of the hazard in order to ensure > that the effects of the first instruction are seen by the second instruction." > > The "Spacing column" value is 3, indeed. > > "With the hazard elimination instructions available in Release 2, the > preferred method to eliminate hazards is to place one of the > instructions listed in Table 2.8 between the producer and consumer of the > hazard. Execution hazards can be removed by using the EHB [...]" Whatever manual you quote it refers to MIPS Release 2, which is only dated 2003 (following Release 1 from 2001), but `__r4k_wait' has to continue handling older architecture revisions going back to MIPS III ISA from 1991. We also support MIPS I ISA from 1985 which has further instruction scheduling requirements, but `__r4k_wait' is for newer processors only, because older ones had no WAIT instruction, so we can ignore them (but note that the MIPS I load delay slot is regardless observed in current code in the form of a NOP inserted after LONG_L). > What am I missing? This is common MIPS knowledge really, encoded in the GNU toolchain and especially GAS since forever. While I can't cite a canonical reference, the hazard is listed e.g. in Table 13.1 "Instructions with scheduling implications" and Table 13.3 "R4xxx/R5000 Coprocessor 0 Hazards" from "IDT MIPS Microprocessor Family Software Reference Manual," Version 2.0, from October 1996. I do believe the document is available online. I'm fairly sure the hazard is also listed there in Dominic Sweetman's "See MIPS Run Linux," but I don't have my copy handy right now. Best is to avoid using a `.set noreorder' region in the first place. But is it really needed here? Does the rollback area have to be of a hardcoded size rather than one calculated by the assembler based on actual machine code produced? It seems to me having it calculated would reduce complexity here and let us use the EI instruction where available as well. HTH, Maciej
