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)