On 15 Feb 2001 eeh@netbsd.org wrote:

> 
> 	On 15 Feb 2001 eeh@netbsd.org wrote:
> 
> 	> 
> 	> 	'unsigned long' triggers compiler to use 'long double' (which might be
> 	> 	reasonable because there are no corresponding  machine op) and that option
> 	> 
> 	> Hm.  Why would using a 64-bit integer type force the use of 128-bit
> 	> floating point?  And what do you mean `no corresponding  machine op'?
> 	> there are both fxtod and fxtoq instructions, although the latter is
> 	> emulated.
> 	> 
> 
> 	V9 book says 'convert the 64-bit signed integer ...', so unsigned makes
> 	difference, SUNWspro compiler also treats them differently. One more
> 
> Yeah, but that has to do with the source type, not the destinattion type.
> The amount of work needed to use `fxtoq' and `fxtod' is the same.  I don't
> think the compiler should be using non-standard types for intermediate
> data if those types are never explicitly used in other parts of the program.
> So a `unsigned long int' can overflow a double.  Big deal.  So can a
> signed `long int'.
> 

No-o-o, it can't overflow, neither one,-). The point is that V9 has machine
instruction which convert only *signed* and compiler writer should find 
a way to deal with unsigned integers, so gcc 'simplified' it by using 
unsigned long -> long double -> double, chosing not to mess with sign bit
and put everything on fpu (sign bit is significant in this case).
BTW, unfortunately, current gcc still does it.
I looked into 'hard-quad' code again - I need it to try on
solaris, just don't know how that's supposed to work.


> 	observation is gcc-current on solaris uses sparc ABI, does netbsd follow
> 	it? And I also noticed some  differences in .rodata access code:
> 
> NetBSD uses the sparc ABI for 32-bit binaries and the sparc v9 abi for
> 64-bit binaries.  They are significantly different.

Said 'sparc ABI', I found that I'm not sure what I've meant, so I went
to www.sparc.com and found there 'Sparc Compliance Definition' which
basicly mix everything from low level to SVID alltogether and call it 
sparc ABI. So I think low level the same. And that was  the question.

> 
> The solaris code uses the `medium anywhere' memory model.  The code you
> see in the NetBSD snipped uses what gcc calls `embed any'.  I thought we
> had changed that...

Those are new words for me;-). "medium anywhere", "embed any"..
I rebuild compiler couple of times so I might screw it. Don't know.

> There are numerouse implementation options in the V9 spec.  If
> you want all the gory details you should get one of the UltraSPARC
> user's manuals from the Sun websites.

I found the link interesting:
http://www.sparc.org/standards.html/V9.implementation.ps.Z

	Andrey