Subject: Re: some success with binutils 2.9.1 as and kernels...
To: None <port-pmax@netbsd.org, port-mips@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 03/07/1999 13:13:03
In message <199903071008.CAA13814@Whisk.DSG.Stanford.EDU>Jonathan Stone writes
>
>I took the biutils 2.9.1 tc-mips.c and replaced the code which handle
>the assembler macro-instruction "divu" (with integer register operands)
>with the old 2.8.1 code (ie, for
>
>test_frag:
>        divu    $4,$4,$2
>        mfhi    $6
>
>it emits
>	divu    $zero,$a0,$v0
>	bnez    $v0,10 <test_frag+10>
>	nop
>	break   0x7
>	mflo    $a0
>	mfhi    $a2
>
>rather than the virgin 2.9.1
>	bnez    $v0,c <test_frag+c>
>	divu    $zero,$a0,$v0
>	break   0x7
>	mflo    $a0
>	mfhi    $a2
>
>
>A GENERIC kernel built linked with the modified binutils-2.9.1 seems
>to work; i'm trying a `make build' on it now.
>
>But i really dont understand why the sequence above fails when used in
>the kernel. i dont see how there are any more hazards or interlock
>problems with one vis-a-vis the other.  The bug also seems to be non-
>deterministic: it odesn't happen in the same place.
>
>It makes me wonder if it's tied up with the divu being in a delay
>slot. (divu takes some 75 cycles on an r4000 or r4400, so its Aa good
>candidate for a exception).  Maybe there's a subtle bug in how we
>handle exceptions in branch-delay slots?

Some more info: a kernel built with the virgin 2.9.1 assembler seems
to work fine on a 5000/50. The same kernel (unless I botched something
in my sleep) crashes on a 5000/150.  Anyone else out there got a 3MIN
or Personal Decstation with a rev 3.0 r4000?

(I suppose, if push comes to shove, I can try exchanging the CPU
  modules and see which way the bug goes...)