Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!mikel@decwrl.DEC.com@pyramid.UUCP
From: mikel@decwrl.DEC.com@pyramid.UUCP
Newsgroups: mod.computers.pyramid
Subject: Re: problem with the interpretation of certain constants
Message-ID: <8703111803.AA01684@pyramid.UUCP>
Date: Wed, 11-Mar-87 13:03:40 EST
Article-I.D.: pyramid.8703111803.AA01684
Posted: Wed Mar 11 13:03:40 1987
Date-Received: Thu, 12-Mar-87 23:47:00 EST
References: <8703092244.AA15530@acdpyr.UCAR.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: pyramid!mikel@decwrl.DEC.COM (Mike Lipsie)
Distribution: world
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 53
Approved: info-pyramid@mimsy.umd.edu

In article <8703092244.AA15530@acdpyr.UCAR.EDU> davis@ACDPYR.UCAR.EDU (Glenn P. Davis) writes: [highly edited]
>
>The following code and script demonstrates a bug
>with the pyramid 'c' compiler, version 3.2.
>
>This code developed as an attempted workaround to
>a similar problem with the fortran compiler,
>hence the underscores and pointer argument.
>
>	 return( *px * ((float)1/128 ) ) ;
>
>generates
>_foo_:
>	movw	(pr0),pr0
>	ret	
>	ret	
>
>[i.e., ignores the (float)1/128]
>
>
>It seems this problem is an artifact specifically of the
>(single precision) floating point representation  of 1/128.
>Other numbers or the double representation of this number
>do not cause problems.
>
>It is interesting to note that this is the  'bias' of
>the single precision exponent field.
>
>
>Glenn P. Davis
>NCAR / ACD

I have already responded by e-mail to Glenn to inform him that
this problem has been fixed in c version 4.0.0 and in f77 version
3.3.2.  He suggested that I post this information since his not
knowing was the reason for his posting in the first place.

So I did a little more research to find out the cause of the bug
in the first place.  As you probably know, Pyramid Technology
computers use the IEEE floating-point formats and compilers are
known to like to represent special floating-point constants as
bit patterns.  The code generator (for c, f77, and pascal)
optimizes out multiplication by one (the plot thickens).  The
single-precision (float) representation of (float)1/128 is 
0x3c000000 and the double-precision (double) representation of 1.0 is 
0x3c000000 0x00000000.  We store all numeric values in two words with 
unused bits zeroed.  So the code generator thought it was optimizing 
out a multiply by one.  The fix involved checking the type field more
closely.
-- 

Mike Lipsie  {allegra,cmcl2,decwrl,hplabs,ut-sally,utzoo}!pyramid!mikel
Pyramid Technology Corp, Mountain View, CA  +1 415 965 7200 ext. 4980