🚀 go-pugleaf

> 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)