On Sun, 26 Jul 1998, Jonathan Stone wrote:

> Think about what happens when we support 64-bit sparc binaries.  Does
> that mean sparc64 becomes a new machine_arch? Todd and Eduardo seem to
> think so.  Does that mean we need separate arch/{sparc,sparc64}
> directories everywhere?  Does it mean CPP no longer predefines
> __sparc__ on a sparc64?  What does that mean for package source that
> wants to compile sparc-specific C source that works in LP32 or LP64
> but just wants to test for "sparc"?   What  does the vendor environment do?

As a matter of fact, yes I do consider sparc64 a different 
__MACHINE_ARCH__.   The stack handling is different.  The argument
passing conventions are different.  The register widths are different.
The load/store instructions are different.  The multiply/divide
instructions are different.  The shift/branch/conditional move
instructions are different. In 64-bit libraries, all the assembly routines
would need to be re-written.  

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.  Unfortunately, we don't have any mechanisms yet to
link in architecture specific libraries dynamically yet.

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