Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsh!wcs From: wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) Newsgroups: comp.arch Subject: Re: Compilers, architecture, and efficiency Message-ID: <1991May13.054124.8193@cbnewsh.att.com> Date: 13 May 91 05:41:24 GMT References: <41279@genrad.UUCP> <9596@cognos.UUCP> Organization: AT&T Bell Labs Random Organization Name Generator Lines: 17 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. Similarly, this is usually the fastest way to do bit-twiddling operations without (or even with) special machine ops. Sure, with a PDP-11 you didn't want to waste 2K or 4K for a table, but on a 4MB machine with shared libraries it's cheap. -- Pray for peace; Bill # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ # I never wanted to be a hacker! I wanted to be --- a lumberjack!