Re: arcbios_calls.S data hazards

["Maciej W. Rozycki" <macro%orcam.me.uk@localhost>]

On Fri, 5 Dec 2025, Steve Rumble wrote:

> I think there are a couple of data hazards in arcbios_calls.S that can
> cause trouble for pre-R4000 CPUs. I suspect this doesn't affect any real
> ARCS machines since their CPUs should detect and stall automatically.
> However, the sgimips port fakes ARCS for older R2k/R3k machines, so it uses
> this code on older CPUs, too.
> 
> Unfortunately, --fatal-warnings didn't catch these.
> 
> Index: arcbios_calls.S
> ===================================================================
> RCS file: /cvsroot/src/sys/dev/arcbios/arcbios_calls.S,v
> retrieving revision 1.4
> diff -u -r1.4 arcbios_calls.S
> --- arcbios_calls.S 30 May 2020 03:16:31 -0000 1.4
> +++ arcbios_calls.S 5 Dec 2025 15:45:52 -0000
> @@ -55,6 +55,7 @@
>   REG_S s0, CALLFRAME_SP(sp)
> 
>   PTR_L t9, _C_LABEL(ARCBIOS)
> + nop
>   PTR_ADDU t9, t0
>   INT_L t9, 0(t9)
>   nop

 Hmm, is there any particular reason why this code uses `.set noreorder'?  
It's the usual source of issues and it does not appear to me there are any 
delay slots that need to be scheduled by hand throughout this source code, 
so relying on the assembler to schedule the slots automatically according 
to the architecture chosen is normally the best way to sort it.

 It is only where there is a data dependency between a branch and its 
delay-slot instruction that the delay slot needs to be scheduled by hand, 
and even then the `.set noreorder' block is best limited to the individual 
instruction pair only.

 ISTM that removing `.set noreorder' and taking instructions manually
scheduled out of the respective delay slots should be the best approach 
long-term maintenance-wise.  For the currently working R4k assembly target 
it should result in identical machine code produced, while for the R3k it 
will fix the bug without penalising R4k targets with extraneous NOPs.

  Maciej