Re: arcbios_calls.S data hazards

[Steve Rumble <stephen.m.rumble%gmail.com@localhost>]

On Fri, Dec 5, 2025 at 8:59 PM Maciej W. Rozycki <macro%orcam.me.uk@localhost> wrote:

>  Hmm, is there any particular reason why this code uses `.set noreorder'?

I don't know. I was hoping someone else would clarify.

If I remove noreorder, the assembler addresses the data hazards.
However, it also adds a nop after each jump, pushing the intended
delay slot instruction back, which introduces a bug. Presumably in
reorder mode one is supposed to write as though the BDS doesn't exist
(i.e., the instruction after a branch in the asm file will always be
executed after the branch). Is that correct?

However, if I move the BDS instruction to before the branch, the
assembler just keeps the same order and adds a nop rather than
reordering to exploit the unused delay slot. If a nop is already
there, it still adds another. I tried passing -O2 to as ("remove
unneeded NOPs and swap branches"), but that made no difference.

Optimising for maintenance is a good point and this code is hardly
performance-critical. But maybe reordering ends up being similarly
tricky in the end? Of the .S files in sys/arch/mips/mips that aren't
just macro expansions, about 80% set noreorder.

Steve