Re: port-mips/57680: printf("%.1f") shows wrong results on R3000mipseb

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

The following reply was made to PR port-mips/57680; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: riastradh%NetBSD.org@localhost
Cc: gnats-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-mips/57680: printf("%.1f") shows wrong results on R3000mipseb
Date: Thu, 16 Nov 2023 02:48:29 +0900

 > > On the other hand, gas from binutils 2.16.1 in netbsd-5 seems to put
 > > necessary(?) nop after lwc1 on assembling the same .s source:
 > > ...
 > >         :       c7a00024        lwc1    $f0,36(sp)
 > >         :       c7a10020        lwc1    $f1,32(sp)
 > > ===>    :       00000000        nop
 > >         :       e7a0002c        swc1    $f0,44(sp)
 > >         :       e7a10028        swc1    $f1,40(sp)
 > 
 > Interesting.  Does this one nop make the difference?  If you assemble
 > the .s file without it, and assemble the .s file with it added, does
 > that make the difference of whether printf works correctly or not?
 > 
 > If this nop does make the difference, that suggests to me that my
 > interpretation of the CPU references we found was wrong -- that the
 > load must be separated by _two_ instructions from any use of the
 > register, not by just one.
 
 The above nop doesn't change the wrong behavior.
 
 After several try and errors, the following two nops
 added to intermidiate dtoa.s file solve problems in
 my first test program:
 
 ---
 --- obj.newsmips/dtoa.s.orig	2023-11-16 02:07:46.447381521 +0900
 +++ obj.newsmips/dtoa.s	2023-11-16 02:24:46.673588550 +0900
 @@ -223,17 +223,17 @@
  
  	lw	$2,%got(__tens_D2A)($28)
  	sll	$3,$16,3
  	addu	$2,$2,$3
  	lwc1	$f0,4($2)
  	lwc1	$f2,36($sp)
  	lwc1	$f1,0($2)
  	lwc1	$f3,32($sp)
 -	#nop
 +	nop
  	c.lt.d	$f2,$f0
  	#nop
  	bc1f	$L314
  	subu	$22,$22,$4
  	addiu	$19,$22,-1
  	addiu	$16,$16,-1
  	.set	noreorder
  	.set	nomacro
 @@ -2367,17 +2367,17 @@
  	.set	macro
  	.set	reorder
  
  	lw	$5,%got($LC9)($28)
  	#nop
  	lwc1	$f8,%lo($LC9+4)($5)
  	#nop
  	lwc1	$f9,%lo($LC9)($5)
 -	#nop
 +	nop
  $L63:
  	mul.d	$f0,$f0,$f8
  	addiu	$5,$23,1
  	trunc.w.d $f4,$f0,$2
  	mfc1	$2,$f4
  	cvt.d.w	$f4,$f4
  	sub.d	$f0,$f0,$f4
  	addiu	$2,$2,48
 
 ---
 
 news3470-% env LD_LIBRARY_PATH=/s/netbsd-9/src/lib/libc/obj.newsmips ldd ./a.out
 ./a.out:
         -lc.12 => /s/netbsd-9/src/lib/libc/obj.newsmips/libc.so.12
 
 [build libc using original dtoa.s]
 
 news3470-% env LD_LIBRARY_PATH=/s/netbsd-9/src/lib/libc/obj.newsmips ./a.out
 300.0
 314
 ?00.0
 1570
 
 [build libc from dtoa.s with the first nop]
 
 news3470-% env LD_LIBRARY_PATH=/s/netbsd-9/src/lib/libc/obj.newsmips ./a.out
 300.0
 314
 1000.0
 1570
 
 [build libc from dtoa.s with both nops]
 
 news3470-% env LD_LIBRARY_PATH=/s/netbsd-9/src/lib/libc/obj.newsmips ./a.out
 314.2
 314
 1570.8
 1570
 news3470-%
 ---
 
 It looks both $f2/$f3 and $f8/$f9 FP register pairs are used as double,
 so as(1) should handle more hazard such case (double that requires
 two FP registers)?
 
 ---
 Izumi Tsutsui