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
observation is gcc-current on solaris uses sparc ABI, does netbsd follow
it? And I also noticed some  differences in .rodata access code:

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

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

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

	Andrey