On 13 Aug 2001 eeh@netbsd.org wrote:

: | Fine to me, except that we should use the NetBSD names for the
: | MACHINE_ARCH for consistency on NetBSD.  We don't have any other direct
: | references to "sparcv9", for instance; this should be "sparc64".  (Although,
: | if the sparc64 default userland is 64-bit, there won't be a -sparc64
: | version, just a -sparc 32-bit version.  8-)
:
: No, I think we should use the architecture-specific name for the binary
: format.  In this case it would be possible to generate a full set of
: sparcv8plus binaries, which are 32-bit, but use v9 instructions and would
: thus be incompatible with the standard sparcv8 binary format.

v8plus is still a v7/v8-compatible binary format which Happens To Use V9
Instructions; thus it *could* use the v7 compiled ld.elf_so and libc, right?

Compiling a v8plus userland as a one-off option doesn't negate this
assertion.  You could make a similar analogy to m68k; the 68040 has a wealth
more instructions than the 68020, but it's still the same binary format and
MACHINE_ARCH.

Thus, a 32-bit dynamic linker and libc on a 64-bit native userland should be
called "sparc" to match our MACHINE_ARCH name; not "sparcv8".

: MIPS illustrates this issue quite well.  Ignoring the inverse-endian issues,
: mips has at least O32, N32, and N64 binary formats, if not more.  All these
: formats are mutually incompatible.

And are separate MACHINE_ARCHs to us, were we to implement all these code
models.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/