Thread View: mod.computers.pyramid
3 messages
3 total messages
Started by Glenn P. Davis
Mon, 09 Mar 1987 22:44
problem with the interpretation of certain constants
Author: Glenn P. Davis
Date: Mon, 09 Mar 1987 22:44
Date: Mon, 09 Mar 1987 22:44
92 lines
2436 bytes
2436 bytes
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.
****
Script started on Fri Nov 7 12:41:35 1986
(acdpyr) 93 % cat foo.c
float
foo_(px)
float *px ;
{
return( *px * ((float)1/128 ) ) ;
}
main()
{
float x = 256 ;
printf("x , foo_(&x) : %f %f\n", x, foo_(&x));
}
(acdpyr) 94 % cc foo.c
(acdpyr) 95 % strings `which cc` | grep @
@(#)$Header: cc.c,v 3.2 86/04/16 14:32:40 george Exp $
(acdpyr) 96 % a.out
x , foo_(&x) : 256.000000 256.000000
(acdpyr) 97 % x
script done on Fri Nov 7 12:43:02 1986
*****
The result should be, of course , 2.000000 .
The same assembly code is produced for
return( *px * ((float) .0078125 ) ) ;
That is:
*** foo.s WRONG ***
.data 0
.data 1
.text 0
.globl _foo_
_foo_:
movw (pr0),pr0
ret
ret
*** end ****
Based on what one gets with other values of the constant,
I would rather expect something like
*** foo.s, RIGHT? ***
.data 0
.data 1
.text 0
.globl _foo_
_foo_:
movw (pr0),pr2
movw $0x3c000000,pr3
mulf pr3,pr2
movw pr2,pr0
ret
ret
*** end *****
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.
Would we have the same problem with a
double precision representation of 1/1024 ???
This is left as an exercise to the reader.
Glenn P. Davis
NCAR / ACD
PO Box 3000
Boulder, CO 80307
(303) 497 - 1489
Re: problem with the interpretation of certain constants
Author: mikel
Date: Wed, 11 Mar 1987 18:03
Date: Wed, 11 Mar 1987 18:03
53 lines
2756 bytes
2756 bytes
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
Re: problem with the interpretation of certain constants
Author: mikel
Date: Wed, 11 Mar 1987 22:49
Date: Wed, 11 Mar 1987 22:49
54 lines
2751 bytes
2751 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads