[comp.sys.encore] Compiler bug or insuficient language definition ?

george@cis.ohio-state.edu (Karl Kleinpaste) (06/01/89)

One of our grad students is trying to write some routines to do generic
parameter passing (i.e. give it the address of a variable, the size
and let bcopy store/fetch the value).  In the process of doing this
we came across some interesting behavior with floating point variables
on the Multimax.  The following piece of code

main()
{
  float f = 4.0;

  printf("float = %f\n", f);
  printf("float = %x\n", f);
}

on a sun and a pyramid will print both the floating point value (4.0) and 
then the raw hex value showing how the floating point number is stored.
On the Multimax the second value is reported as 0.  Is this (a) a compiler
bug (b) a fuzzy area in the definition of C (c) other ?

Thanks,
---George Jones
OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325
george@cis.ohio-state.edu or ...!osu-cis!george
Wishing you joy as you celebrate Christmas !

goldman@xenna.UUCP (Steve Goldman) (06/01/89)

  Answer is (c) other. Multimax floating point is little endian. f is promoted
to double on each printf call. The second call dutifully prints the low order
32 bits of the mantissa which are zero. On a big endian machine you'd get the
high order bits which in this case are much more interesting.

Steve Goldman, Encore Computer Corp          (919) 481-3730
901 Kildaire Farm rd., bldg D  Cary, NC  27511       USA
arpa: goldman@Encore.COM (129.91.1.14)
uucp: {necntc,talcott,decvax,allegra}!encore!goldman
Steve Goldman, Encore Computer Corp          (919) 481-3730
901 Kildaire Farm rd., bldg D  Cary, NC  27511       USA
arpa: goldman@Encore.COM (129.91.1.14)
uucp: {necntc,talcott,decvax,allegra}!encore!goldman

drs@bnlux0.bnl.gov (David R. Stampf) (06/02/89)

In article <50537@tut.cis.ohio-state.edu> george@cis.ohio-state.edu (Karl Kleinpaste) writes:
>on the Multimax.  The following piece of code
>
>main()
>{
>  float f = 4.0;
>
>  printf("float = %f\n", f);
>  printf("float = %x\n", f);
>}
>
>on a sun and a pyramid will print both the floating point value (4.0) and 
>then the raw hex value showing how the floating point number is stored.
>On the Multimax the second value is reported as 0.  Is this (a) a compiler
>bug (b) a fuzzy area in the definition of C (c) other ?
>
>Thanks,
>---George Jones

	On the multimax, the sizeof(double) is 8 bytes, sizeof(long) is 4 bytes
and I would venture a guess that the floating format has the words in opposite
order from sun/pyramid.  The printf converts f to a double, then pushes it on
the stack which looks like this.

			00000000	<- least sig. bits of 4.0
			04010000	<- or something like this for msb

	The %x (or %lx) picks off the top one and obediently prints 0.  If you
had written instead:

	printf("%lx %lx\n",f);

	you would see the correct format.  Had you said f = 2.0/3.0, you would
have seen something that looked better, but it would have been wrong, since you
would only see the lower bits.

	< dave

guy@auspex.auspex.com (Guy Harris) (06/03/89)

>If you had written instead:
>
>	printf("%lx %lx\n",f);
>
>	you would see the correct format.

At least on some implementations, including, presumably, the Encore one. 
If you *really* want to dump the bits of a value in a way that doesn't
depend on the details of parameter passing, write a "dump bits" routine
that takes a "char *" (or "unsigned char *") and perhaps a byte count,
and do

	dump_bits((char *)&f, sizeof f);

or something like that.