🚀 go-pugleaf

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