NetBSD Problem Report #4236
Received: (qmail 7099 invoked from network); 8 Oct 1997 04:47:15 -0000
Message-Id: <199710080045_MC2-232C-378F@compuserve.com>
Date: Wed, 8 Oct 1997 00:43:18 -0400
From: Norman Mackenzie <101564.312@compuserve.com>
Sender: Norman Mackenzie <101564.312@compuserve.com>
To: netbsd bugs <gnats-bugs@gnats.netbsd.org>
Subject: mac68k fscale emulation
>Number: 4236
>Category: port-m68k
>Synopsis: m68k fscale emulation is faulty
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: is
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Oct 07 21:50:02 +0000 1997
>Closed-Date: Thu Oct 09 19:15:38 +0000 1997
>Last-Modified: Thu Oct 09 19:19:18 +0000 1997
>Originator: Norman Mackenzie
>Release: 1.2
>Organization:
>Environment:
mac68k, Performa 600, netbsd1.2, no-FPU math libs
System: NetBSD myname.my.domain 1.2B NetBSD 1.2B (GENERICSBC) #9: Wed Nov 6
04:38:17 CST 1996 scottr@spot:/usr/src/sys/arch/mac68k/compile/GENERICSBC
mac68k
>Description:
The current emulation of the 68881/2 fscale instruction doesn't do anything
for the cases
fscalex, fscaled, fscales and fscalel. The floating point register the
instruction is applied to remains unchanged. Therefore the following code
will produce an incorrect result (1.2 rather than 4915.2)
double d, e;
d = 1.2;
e = d * 4096;
since gcc recognises the power of two, optimises away the multiplication
and uses "fscalel #12,fp0" to directly change the exponent.
>How-To-Repeat:
The following assembler file tests the faulty instructions. All examples
should give the same result so six identical lines should appear. Only the
fscalew case works with fpu emulation. (Sorry its a mess and uncommented.
It's hacked output from gcc and I don't know much about the assembler.)
- - - - - - - - - - - -
#NO_APP
gcc2_compiled.:
___gnu_compiled_c:
.text
Ltext0:
LC0:
.ascii "%g, %g\12\0"
.even
.globl _main
.type _main,@function
_main:
link a6,#-36
jbsr ___main
LBB2:
movel #1076407828,a6@(-8)
movel #2061584302,a6@(-4)
moveq #5,d1
movel d1,a6@(-20)
movew #5,a6@(-22)
movel #0x40a33333,a6@(-26)
movel #1075078758,a6@(-34)
movel #1717986918,a6@(-30)
fmoved a6@(-8),fp1
fscalel #5,fp1
fmoved fp1,a6@(-16)
movel a6@(-12),sp@-
movel a6@(-16),sp@-
movel a6@(-4),sp@-
movel a6@(-8),sp@-
pea LC0
jbsr _printf
addw #20,sp
fmoved a6@(-8),fp1
fscalel a6@(-20),fp1
fmoved fp1,a6@(-16)
movel a6@(-12),sp@-
movel a6@(-16),sp@-
movel a6@(-4),sp@-
movel a6@(-8),sp@-
pea LC0
jbsr _printf
addw #20,sp
fmoved a6@(-8),fp1
fscalew a6@(-22),fp1
fmoved fp1,a6@(-16)
movel a6@(-12),sp@-
movel a6@(-16),sp@-
movel a6@(-4),sp@-
movel a6@(-8),sp@-
pea LC0
jbsr _printf
addw #20,sp
fmoved a6@(-8),fp1
fscales a6@(-26),fp1
fmoved fp1,a6@(-16)
movel a6@(-12),sp@-
movel a6@(-16),sp@-
movel a6@(-4),sp@-
movel a6@(-8),sp@-
pea LC0
jbsr _printf
addw #20,sp
fmoved a6@(-8),fp1
fscaled a6@(-34),fp1
fmoved fp1,a6@(-16)
movel a6@(-12),sp@-
movel a6@(-16),sp@-
movel a6@(-4),sp@-
movel a6@(-8),sp@-
pea LC0
jbsr _printf
addw #20,sp
fmoved a6@(-8),fp1
fmoved a6@(-34),fp0
fscalex fp0,fp1
fmoved fp1,a6@(-16)
movel a6@(-12),sp@-
movel a6@(-16),sp@-
movel a6@(-4),sp@-
movel a6@(-8),sp@-
pea LC0
jbsr _printf
addw #20,sp
LBE2:
L5:
unlk a6
rts
Lfe1:
.size _main,Lfe1-_main
- - - - - - - - - - - -
>Fix:
The variable scale in the function fpu_emul_fscale in the file
/usr/src/sys/arch/m68k/fpe/fpu_fscale.c is added to the exponent of the
destination floating point number. This variable is only set for the cases
fscalew and fscaleb. It is initialised to 0 at the start of the routine.
Therefore the other cases leave the destination floating point number
unchanged.
The file can be fixed with the following changes. After these changes the
above program produces what I would expect for the cases tested. (NB. I
haven't tested this on a machine with a floating point coprocessor so I am
making assumptions about the operation of fscale based on the Motorola
MC68881/882 User's Manual. It does look like a simple oversight in the
original coding though.)
*** /sys/arch/m68k/fpe/fpu_fscale.c Wed Oct 8 02:04:51 1997
--- fpu_fscale.c Wed Oct 8 02:14:23 1997
***************
*** 89,95 ****
}
fpu_explode(fe, &fe->fe_f2, FTYPE_EXT, &fpregs[format * 3]);
fpu_implode(fe, &fe->fe_f2, FTYPE_LNG, buf);
- scale = buf[0];
} else {
/* the operand is in memory */
if (format == FTYPE_DBL) {
--- 89,94 ----
***************
*** 153,159 ****
}
if (format == FTYPE_LNG) {
/* nothing */
- scale = buf[0];
} else if (format == FTYPE_WRD) {
/* sign-extend */
scale = buf[0] & 0xffff;
--- 152,157 ----
***************
*** 170,176 ****
format == FTYPE_EXT) {
fpu_explode(fe, &fe->fe_f2, format, buf);
fpu_implode(fe, &fe->fe_f2, FTYPE_LNG, buf);
- scale = buf[0];
}
/* make it look like we've got an FP oprand */
fe->fe_f2.fp_class = (buf[0] == 0) ? FPC_ZERO : FPC_NUM;
--- 168,173 ----
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->gnats-admin
Responsible-Changed-By: mikel
Responsible-Changed-When: Wed Oct 8 00:03:06 1997
Responsible-Changed-Why:
category changed from 'pending'.
State-Changed-From-To: open->analyzed
State-Changed-By: is
State-Changed-When: Thu Oct 9 08:11:46 PDT 1997
State-Changed-Why:
Assuming the provided patch is reversed, this looks right.
I'll apply & test at home before comitting.
-is
Responsible-Changed-From-To: gnats-admin->is
Responsible-Changed-By: is
Responsible-Changed-When: Thu Oct 9 08:11:46 PDT 1997
Responsible-Changed-Why:
I'll look at this.
-is
State-Changed-From-To: analyzed->closed
State-Changed-By: is
State-Changed-When: Thu Oct 9 12:15:38 PDT 1997
State-Changed-Why:
Applied patch manually.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.