www.delorie.com/djgpp/bugs/show.cgi   search  
Bug 000075

When Created: 04/11/1996 19:26:36
Against DJGPP version: 2.00
By whom: lehmann@mathematik.th-darmstadt.de
Abstract: IEEE float special value for +1/-1 don't always work. (emu387)
I have tried around a bit with IEEE floats while writing float support for FITS files and I think I
noticed an inconsistency in the handling of IEEE special values in the 387 emulator:

In addition to the normal value of +1, the IEEE spec defines (for reasons unknown to me) a special
value +1 and -1, which look like this (float in hex notation, not as memory bytes):

+1 7F800000, -1 FF800000

(the normal value for +1 is 3f8..)

Apparently these values are handled in the emulator, but not in all cases, assume the following code:

int main(void)
{
  long l=0x7f800000;

  printf("%f\n", *(float*)&l);
  *(float*)&f*=5;
  printf("%f\n", *(float*)&l);
  *(float*)&f;
  printf("%f\n", *(float*)&l);  
}

The program produces the following output:

1.00000
1.00000
5.00000

It seems that the first multiplication doesn't change the value, but after it, the value is stored as
a regular +1, which means that the next multiplication works. Apparently the first printf works, since
there is some kind of calculation applied to the value that also causes it to be converted to a normal +1.

So probably the code to normalize numbers checks for the IEEE specials, but the code to the calculations
doesn't.


May also someone could test this on a CPU with float processor, according to some Intel assembler book,
the handling of IEEE values differs between the different CPU generations.

The whole thing is not a big problem, since only normal values will appear in caculations done by the
CPU itself, but if some kind of external data is read, the special values could occur.

Note added: 04/11/1996 19:57:32
By whom: lehmann@mathematik.th-darmstadt.de
Hm, it seems that the www bug interface does some backslash processing I didn't expect.
But you know what I meant, I hope.

Note added: 04/13/1996 07:54:06
By whom: terra@diku.dk (Morten Welinder)
emu387 is known to have a number of bugs ("flaws", if you like).
Reduced accuracy for certain functions (exp, for example) at
certain data points is one of these.  You're likely to have
found another.

The general feeling is that emu387 is not worth giving too much
attention with the low price that FPUs have these days.  If you
do serious work you should get an FPU anyway, for speed reasons.

You just might be able to get better results with the alternative
FPU emulator.

Closed on 04/13/1999 08:00:58: A known flaw in the FPU emulator that isn't worth fixing.
By whom: eliz@is.elta.co.il



  webmaster     delorie software   privacy  
  Copyright © 2010   by DJ Delorie     Updated Jul 2010