On Mon, 27 Jul 1998, Todd Vierling wrote:

> On Mon, 27 Jul 1998, Eduardo E. Horvath wrote:
> 
> : Even in 32-bit land it makes sense to separate the architectures.  Much
> : better to issue a nice fast multiply than use multiply-step instructions.
> : More importantly, bcopy() can be re-coded to use block move instructions
> : for a huge performance increase.  Without this sort of optimization, the
> : machines run dog-slow.
> 
> Then sparc64 probably should become its own MACHINE_ARCH so that it can make
> use of all of this.
> 
> :  Unfortunately, we don't have any mechanisms yet to
> : link in architecture specific libraries dynamically yet.
> 
> This isn't as useful as it may seem for sparc V8 vs. sparc V9; you'd really
> want to compile the whole of libc for V9.  And if you're going to do that,
> and have other speedups to use (different argument passing conventions,
> different stack structuring), it may as well be useful to split the
> MACHINE_ARCH as part of that.

In a mixed sparc/sparc64 environment it might be better to have one set of
NFS mounted binaries.  If you're running old sparcV8 executables (under
emulation?), you would want to be able to make use of more efficient
instructions and get the resulting performance boost in the libraries.  So
you would want one full 64-bit API v9-specific userland, and one 32-bit
API v9-specific set of libraries for running old SPARCv8 binaries (and
some old-fashioned v8 static libraries to generate static binaries).

The problem is: how do you build a separate set of 32-bit and 64-bit v9
libraries?  Two MACHINE_ARCHes?

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