Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Floats, doubles C and MSVC

Reply
Thread Tools

Re: Floats, doubles C and MSVC

 
 
Andrew Reilly
Guest
Posts: n/a
 
      10-14-2004
On Wed, 13 Oct 2004 23:18:00 +0100, John Dallman wrote:
> In article <(E-Mail Removed)-users.org>,
> http://www.velocityreviews.com/forums/(E-Mail Removed)-users.org (Andrew Reilly) wrote:
>
>> I've discovered an unexpected problem with some signal processing code
>> that I've been testing on various C platforms. I had been developing
>> with GCC under FreeBSD and MacOSX, and didn't have any problems.
>> When some of my colleagues ran it under Windows (compiled by MSVC),

>
> Which version of MSVC? 4.0 or later are OK; they set up the x87 FPU to use
> honest 64-bit doubles, rather than the 80-bit kind. I don't know about
> MSVC2.0, but MSVC 1.x uses 80-bit arithmetic


MSVC is version 6.

> And what flags? Try adding the "/Op" flag for "Improved floating-point
> consistency". That often fixes these problems; the default settings are a
> bit wild-and-wooly.


Thanks for the suggestion. I'll pass it on to my MSVC-constrained
colleagues.

The issue seems (to me) to devolve into: "under what circumstances, in C,
can one rely on cast from "double" to "float" to "take", when the original
double value is still in scope?" There seem to be some weasel words in
the C (C++ only?) standard about compilers being allowed to "be
represented in greater precision and range than that required by the type".

Hmm. Looking at that again, that post again (the first one by Ken Hagen),
it only refers to operands and results of expressions. So values passed
between statements, in variables, must presumably have the type cast
applied to them, even if they are subsequently manipulated in double
precision again?

I.e.:

double get_LSBs(double d) { return d - (float)d; }

might legitimately always return zero, because (float)d is an operand in a
floating point expression and may actually be used as just d, but

double get_LSBs(double d) { float f = (float) d; return d - f; }

should be able to be relied upon to return a value derived from the LSBs
of d. Right?

If that's the case, then MSVC-6 is definitely doing the wrong thing.

Could my previous idea of doing the cast with a separate function:
float float_me(double d) { return (float)d; }
even be expected to work, given that the x86-32 ABIs seem to return
floating point results in TOS of the x87?

Cheers,

--
Andrew
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      10-14-2004
This was discussed in comp.std.c some time ago.

The standard implies that casts from double to float and the
other way around should be actually done, i.e. the precision should
be shed and the number, even if *represented* in
greter precision should be converted to 24 bit precision.

lcc-win32 implements this by storing the long double
format used internally into memory, then re-reading it again.

The same happens with the conversion of long double to
double and the other way around
 
Reply With Quote
 
 
 
 
Tim Prince
Guest
Posts: n/a
 
      10-14-2004

"Andrew Reilly" <(E-Mail Removed)-users.org> wrote in message
news(E-Mail Removed)-users.org...
> On Wed, 13 Oct 2004 23:18:00 +0100, John Dallman wrote:
> > In article <(E-Mail Removed)-users.org>,
> > (E-Mail Removed)-users.org (Andrew Reilly) wrote:
> >
> >> I've discovered an unexpected problem with some signal processing code
> >> that I've been testing on various C platforms. I had been developing
> >> with GCC under FreeBSD and MacOSX, and didn't have any problems.
> >> When some of my colleagues ran it under Windows (compiled by MSVC),

> >
> > Which version of MSVC? 4.0 or later are OK; they set up the x87 FPU to

use
> > honest 64-bit doubles, rather than the 80-bit kind. I don't know about
> > MSVC2.0, but MSVC 1.x uses 80-bit arithmetic

>
> MSVC is version 6.
>
> > And what flags? Try adding the "/Op" flag for "Improved floating-point
> > consistency". That often fixes these problems; the default settings are

a
> > bit wild-and-wooly.

>

That's correct. /Op includes the same effect as you would see in gcc
with -ffloat-store.
With x87 code, performing a true conversion from double to float and back to
double, as required for further arithmetic, is extremely time-consuming. It
requires at least that the entire cache line be updated at all levels of
cache, presumably with "joined at the bus" acceleration to get your operand
back prior to finishing those updates. This is one of the reasons why all
CPUs in those families from P-III and Athlon on provide SSE floating point
instructions. MSVC6 was probably the last widely used compiler which didn't
provide an option to use SSE at least for scalar instructions.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how do you convert and array of doubles into floats? SpreadTooThin Python 7 09-16-2006 01:14 AM
doubles and integers Paul Morrison Java 2 01-04-2005 09:25 PM
Problems with multiplications of doubles and/or floats J.K. Becker C++ 43 04-23-2004 10:41 PM
floats doubles long doubles dan C++ 1 11-26-2003 05:12 AM
unions with long long ints and doubles? Chris N. Hinds C Programming 3 10-01-2003 11:25 PM



Advertisments