🚀 go-pugleaf

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