[comp.bugs.4bsd] Bug converting unsigned to double in BSD 4.23

jsdy@hadron.UUCP (Joseph S. D. Yao) (11/18/86)

In article <213@cartan.Berkeley.EDU> ballou@brahms (Kenneth R. Ballou) writes:
>main ()
>{
>  printf ("%u\n", ~ ((unsigned) 0));
>  printf ("%lf\n", (double) (~ ((unsigned) 0)));
>  printf ("%lf\n", 4294967295.0); /* surely double is large enough for this? */
>}
>% bug
>4294967295
>-1.000000
>4294967295.000000

This didn't work (actually, worked as expected!) on our ISI 68000-
based machine.  It worked as above when I compiled and ran it on
the VAX.  What's happening on the VAX is that it's folding the
constant (~((unsigned int) 0)) to the bit pattern $-1, while the
68K is clearing and negating a register: no problem so far!  But
apparently type is lost or ignored on the VAX, because it then
does a cvtld (convert long to double).  This is clever-not-clever
use of the VAX FP instruction set, which doesn't have an unsigned
long data type.  The 68K calls a subroutine:
	jbsr	dpufloat
which comprehends and translates unsigned longs, as dpfloat does
for signed longs.  (Doing it in software has occasional advantages
over doing it in hardware.)
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
			jsdy@hadron.COM (not yet domainised)

guy@sun.uucp (Guy Harris) (12/01/86)

> But apparently type is lost or ignored on the VAX, because it then
> does a cvtld (convert long to double).  This is clever-not-clever
> use of the VAX FP instruction set, which doesn't have an unsigned
> long data type.

Not on 4.3BSD, it doesn't!  It generates a "movd", but the constant it moves
is "-1.0", not "4.2949...e9".

It's probably due to the following bit of bizarre code in "makety" in
"trees.c" - that's part of the machine-independent code, so it will affect
other machines:

	if( p->in.op == ICON && p->tn.rval == NONAME){
		if( t==DOUBLE||t==FLOAT ){
			p->in.op = FCON;
			if( ISUNSIGNED(p->in.type) ){
				p->fpn.dval = /* (unsigned CONSZ) */ p->tn.lval;
				}
			else {
				p->fpn.dval = p->tn.lval;
				}

			p->in.type = p->fn.csiz = t;
			return( clocal(p) );
			}
		}

The commented-out cast is rather peculiar.  If you uncomment it, it looks
like it should work - and it does, at least where I tried it.

> The 68K calls a subroutine:
> 	jbsr	dpufloat
> which comprehends and translates unsigned longs, as dpfloat does
> for signed longs.  (Doing it in software has occasional advantages
> over doing it in hardware.)

*Our* 68Ks don't do this - they do the conversion at compile time, as they
should!  (Although our compiler currently generates code that does the same
wrong thing that the code generated by the VAX compiler does.)  It's not a
question of whether it's done in hardware or software; it's a question of
whether the compiler does the conversion correctly at compile time or not.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)