Thu, 6 Apr 1995 12:22:30 GMT

Related articles |
---|

Q: division vs multiplication t.hulek@imperial.ac.uk (1995-03-24) |

Re: Q: division vs multiplication kptben@aol.com (1995-04-02) |

Re: Q: division vs multiplication Terje.Mathisen@hda.hydro.com (1995-04-02) |

Re: Q: division vs multiplication mikeq@primenet.com (1995-04-02) |

Re: Q: division vs multiplication hbaker@netcom.com (1995-04-03) |

Re: Q: division vs multiplication davidm@Rational.COM (1995-04-03) |

Re: Q: division vs multiplication brandis@inf.ethz.ch (1995-04-04) |

Re: Q: division vs multiplication Terje.Mathisen@hda.hydro.com (1995-04-06) |

Re: Q: division vs multiplication meissner@cygnus.com (Mike Meissner) (1995-04-16) |

Re: Q: division vs multiplication martens@cis.ohio-state.edu (1995-04-16) |

Re: Q: division vs multiplication jmccarty@spdmail.spd.dsccc.com (1995-04-18) |

Re: Q: division vs multiplication leichter@zodiac.rutgers.edu (1995-04-11) |

Re: Q: division vs multiplication kptben@aol.com (1995-04-17) |

Re: Q: division vs multiplication pcg@aber.ac.uk (1995-04-17) |

[5 later articles] |

Newsgroups: | comp.compilers |

From: | Terje.Mathisen@hda.hydro.com (Terje Mathisen) |

Keywords: | arithmetic, optimize |

Organization: | Hydro Data, Norsk Hydro (Norway) |

References: | 95-04-003 95-04-057 |

Date: | Thu, 6 Apr 1995 12:22:30 GMT |

hbaker@netcom.com (Henry Baker) writes:

*>The problem isn't in the compiler optimization phase, but in the compiler*

*>input phase. There are some compiler input phases that don't properly*

*>read decimal constants, resulting in mangled constants. If you contact*

*>the compiler vendor, they usually don't consider that a 'bug'. However,*

*>if you provide an _integer_ and the compiler input phase mangles it, then*

*>you can usually convince the compiler vendor to fix it.*

*>*

*>For this reason, I have found a/1048576 to be more robust/portable than*

*>multiplying by its inverse.*

Have you tried to define the needed constant as a long, and then

casting the binary value to a float when you need it?

As long as both integer and floating point values are stored with the same

endian-ness, this should work. (Assuming normal IEEE fp encodings.)

I.e., for the Pentium FPATAN workaround I needed to be able to multiply by

1/16, which I encoded directly as:

static unsigned long one_sixteenth = 0x3d800000;

That evaluates to a biased exponent of -4, and a mantissa of 1.0, when

accessed as:

*(float *) &one_sixteenth;

I do agree that a/1048576 is probably a _lot_ more portable than a cast

of (0x35800000) to (float)! :-)

-Terje Mathisen (include std disclaimer) <Terje.Mathisen@hda.hydro.com>

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.