On Sat, 22 May 1999, matthew green wrote:

>    
>    
>    OTOH, the Linux SPARC V9 port is also suffering from these problems.  They
>    get around this by not supporting 64-bit userland, like Solaris2.5-2.6, or
>    so I hear.
> 
> 
> not supporting meaning not providing?  do they run correctly compiled
> 64bit programs?  i noticed that most of the 'userland' in solaris 7 64bit
> is still 32bit (very very few parts were)... of course the kernel has both
> 32bit and 64bit parts entirely.

I read that in some article about Linux.  I don't really know the details,
although they did mention they hoped to get the compiler working by the
end of the year 8^).

Solaris 7 OTOH uses 32-bit binaries because few of the bundled utilities
are performance sensitive (gee, my `ls' takes 5 microseconds less than
your `ls'), the performance differences are relatively small in most cases
and there are instances in a networked environment where a 32-bit machine
may want to run a binary located on a 64-bit machine, so binaries default
to 32-bits.  

> is there a reason to use 64bit programs except where you *need* those bigger
> pointers and longs?  i just see it wasting more memory than necessary... 

The SPARC V9 instruction set is much more amenable to optimization than
the older instruction set.  Predicted branches, prefetching, non-faulting
loads and 64-bit arithmetic can make a major performance difference
despite the extra overhead due to 64-bit pointers' larget memory
footprint.  We have seen cases where I/O devices can be overloaded by
64-bit kernels but not 32-bit kernels, despite the extra overhead needed
to truncate addresses to 32-bits to feed the controllers.  The only
explanation we could find for this is the quality of the 64-bit compilers.

(N.B. this is a good reason to run 64-bit solaris if you have the RAM.
Most of the 32-bit drivers are compiled for the SPARC V8 instruction set.)

> now that NetBSD/sparc is going to be ELF shortly, the ports can share the
> programs.  now is when we really need libc_march shared libraries to ensure
> that the right SPARC architecture uses the most efficient bits available..
> again, like solaris does...

This is somewhat a moot point until we can get a compiler that generates
decent 64-bit code, but there will certainly be things that use the kvm
libraries that need to be compiled 64-bit to grovel through the kernel.
And if that's the case we don't really want to need two different
toolchains to build a distribution.  But loading an architecturally
optimized libc for running emulated binaries would be a good thing.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me