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'.

	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.

		.section	".rodata"
		.align 8
	.LLC0:
		.asciz	"%g\n"

	solaris:
		sethi	%hh(.LLC0), %o0
		or	%o0, %hm(.LLC0), %o0
		sllx	%o0, 32, %o0
		sethi	%lm(.LLC0), %o1
		add	%o0, %o1, %o0
		or	%o0, %lo(.LLC0), %o0

	netbsd:
		sethi	%hi(.LLC0), %o1
		add	%o1, %g4, %o0
		add	%o0, %lo(.LLC0), %o0

	Is %g4 somewhat special for netbsd? Would it be a problem with data
	segment location?

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

	> 	forces compiler to use just 'double' instead. That what I see from
	> 	code generated. I don't know why 'hard-quad-float'd code doesn't work,
	> 
	> All quad instructions are emulated, so you need to debug the kernel
	> fpu emulation code.

	Could you give some poiners where to look. locore?

src/sys/arch/sparc/fpu

	As a reference I have 'Sparc  Architecture Manual V9' so I naively
	thought it all executed by processor itselt.

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.

Eduardo