Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!augean!sibyl!ian From: ian@sibyl.eleceng.ua.OZ (Ian Dall) Newsgroups: comp.arch Subject: Re: Alignment on RS/6000 Message-ID: <897@sibyl.eleceng.ua.OZ> Date: 25 Nov 90 00:28:49 GMT References: <893@sibyl.eleceng.ua.OZ> <46760@apple.Apple.COM> Reply-To: ian@sibyl.OZ (Ian Dall) Organization: Engineering, Uni of Adelaide, Australia Lines: 29 In article <46760@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes: >[] >In article <893@sibyl.eleceng.ua.OZ> ian@sibyl.eleceng.ua.OZ (Ian Dall) writes: >> >> In a similar vein, how many people have been caught by a floating point >> program taking "forever" on a sparc (no doubt othe machines as well) >> because it was spending all it's time doing NaN and Inf exception >> handling? > >Its always been my impression that NaN, Inf, and Denorms were reasonably >rare- they don't usually occur. Is this not the case? Are there statistics >somewhere that show how often these cases occur? In a well behaved program they are extremely rare. Therefore, if they occur you almost certainly have a bug and you might as well core dump. Once one occurs, they tend to be contageous, so that soon your program is trapping on every floating point operation. *That* is what makes it take "forever". The output of such a program is useless. The results are meaningless and worse, they give you no clue as to where the problem might be. A core dump is preferable except maybe in commercial software, and even then it only gives an illusion of robustness. -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others. ACSnet: ian@sibyl.eleceng.ua.oz internet: ian@sibyl.eleceng.ua.oz.au