Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Jul 2001 21:37:55 -0700
From:      Jim Pirzyk <Jim.Pirzyk@disney.com>
To:        Jordan Hubbard <jkh@freebsd.org>
Cc:        jmcoopr@webmail.bmi.net, stephen@math.missouri.edu, freebsd-hackers@freebsd.org
Subject:   Re: math library difference between linux emulation and nativefreebsd (and native linux)
Message-ID:  <01071421375504.00729@snoopy>
In-Reply-To: <20010714210856G.jkh@freebsd.org>
References:  <200107141907.MAA07030@smtp.bmi.net> <01071421031403.00729@snoopy> <20010714210856G.jkh@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 14 July 2001 09:08 pm, you wrote:
> Seems a reasonable thing to do - have you found where in the linux
> compatability code one might set it?

I orginally though in the linux_sendsig routine, where the fpstate
structure is (there is even a int called 'cw').  I tried setting
it there before without any luck (but I do not remember the value
that I used).  I may do some more investigating on it.

- JimP

> From: Jim Pirzyk <Jim.Pirzyk@disney.com>
> Subject: Re: math library difference between linux emulation and native
> freebsd (and native linux) Date: Sat, 14 Jul 2001 21:03:14 -0700
>
> > So the solution to my problem was to set the __INITIAL_NPXCW__ to
> > 0x37F.  What I can think of is that the freebsd binary sets
> > the Control Word to this before running but the linux binary
> > does not (because it is assumed to already be set by the kernel
> > at boot time).  So I would think the linux kernel module would need
> > to set it also.
> >
> > - JimP
> >
> > On Saturday 14 July 2001 12:00 pm, jmcoopr@webmail.bmi.net wrote:
> > > In <3B50966E.1D6E5DCC@math.missouri.edu>, on 07/14/2001
> > >    at 01:58 PM, Stephen Montgomery-Smith <stephen@math.missouri.edu>
> > >
> > > said:
> > > >Yes, I tried out the program
> > > >
> > > >#include <stdio.h>
> > > >#include <math.h>
> > > >main() {
> > > >  double x,y;
> > > >  int i;
> > > >
> > > >  x = 53.278500;
> > > >  y = exp(x);
> > > >  printf("%8lf\n",x);
> > > >  for(i=0;i<sizeof(double);i++)
> > > >    printf("%x ",((unsigned char*)(&x))[i]);
> > > >  printf("\n");
> > > >  printf("%8lf\n",y);
> > > >  for(i=0;i<sizeof(double);i++)
> > > >    printf("%x ",((unsigned char*)(&y))[i]);
> > > >  printf("\n");
> > > >}
> > > >
> > > >On FreeBSD and Linux I get
> > > >53.278500
> > > >cf f7 53 e3 a5 a3 4a 40
> > > >137581029243568449912832.000000
> > > >e7 7d 89 54 48 22 bd 44
> > > >
> > > >and on Linux emulation under FreeBSD I get
> > > >53.278500
> > > >cf f7 53 e3 a5 a3 4a 40
> > > >137581029243567812378624.000000
> > > >c1 7d 89 54 48 22 bd 44
> > > >
> > > >I don't really know the format of IEEE very well, but it looks like
> > > >some low order bits are different - the answers are really different.
> > > >
> > > >I also tried the same experiment with sin and gamma - then the problem
> > > >does not occur.  Well except that the answer for gamma(53.278500) is
> > > >reported as 157.464664 which is way wrong.
> > > >
> > > >When I tried it for x=52 they gave almost the same answer, only
> > > >seperated by the last bit (the decimal versions were reported as the
> > > >same).  For x=54 they both gave the same wrong answer 160.331128.
> > > >
> > > >I don't know a whole lot about IEEE.  What is the largest number it is
> > > >supposed to handle?  Looking at man math it says it should handle
> > > >numbers as large as 1.8e308 - we certainly are not in that range!!!
> > >
> > > But remember, floating point is DIFFERENT--nothing is exact.  You can
> > > create a number with a magnitude about 1.8e308, but you sure don't get
> > > 308 significant digits.  Very big and very small floating point
> > > quantities need special treatment to avoid all sorts of underflow,
> > > overflow, singularity, degraded precision, etc.  Naive, calculator-like
> > > assumptions about floating point will get one into trouble very, very
> > > quickly.
> > >
> > > The real question should be how many significant digits are the Linux /
> > > FreeBSD implementations alike.
> > >
> > > For:
> > >
> > > 4-byte floats--6 digits is all you're likely to get, the rest is noise
> > > 8-byte doubles--12-13 digits is all that is reasonable
> > > 10-byte long doubles--15 digits, and then the world falls in
> > >
> > > Expectations beyond this are beyond the capability of i386 floating
> > > point hardware.  They're also way beyond what you usually need.
> > >
> > > jmc
> > >
> > >
> > >
> > > ------------------------------------------------------
> > > jmcoopr@webmail.bmi.net
> > >
> > > Using OS/2 since 1.0
> > > ------------------------------------------------------
> >
> > --
> > --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
> >     __o   Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org
> >  _'\<,_   Senior Systems Engineer, Walt Disney Feature Animation
> > (*)/ (*)
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message

-- 
--- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $
    __o   Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org
 _'\<,_   Senior Systems Engineer, Walt Disney Feature Animation 
(*)/ (*)  

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01071421375504.00729>