Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin From: hrubin@pop.stat.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: Compilers, architecture, and efficiency Message-ID: <12249@mentor.cc.purdue.edu> Date: 13 May 91 09:25:57 GMT References: <41279@genrad.UUCP> <9596@cognos.UUCP> <1991May13.054124.8193@cbnewsh.att.com> Sender: news@mentor.cc.purdue.edu Lines: 26 In article <1991May13.054124.8193@cbnewsh.att.com>, wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes: > In article <9596@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes: > ]The problem with this is that the compiler rarely has enough > ]information to determine if it's "safe" to just bump the exponent. > ]Therefore it's left with the choice of doing a number of runtime > ]checks (is f equal to zero? Is exponent already at upper limit?), or > ]just punting and generating the naive "multiply by 2.0" instruction. > > Of course, if your compiler includes the library support for it, it > COULD do a table lookup to find the new exponent, or to find that it > needs to do a real multiply. I suggest we look at the steps involved in carrying out this suggestion. First, we need to extract the exponent. Second, we need to do the table lookup. Third, we need to check for overflow/underflow and take the appropriate acticts. Fourth, we need to put the exponent back. It would probably be cheaper not to do the table lookup but to just include the instructions to check for overflow/underflow in the integer part of the operation. But this checking, plus the extraction/insertion, are likely to be considerably more expensive than the floating multiply. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)