On Sat, 25 Jul 1998, Jonathan Stone wrote:

: >Only if it's changing the _default_ output of the toolchain to something not
: >compatible with other machines in the MACHINE_ARCH.  Command line switches,
: >as said before, don't count.

: Same if I compile up an m68k userland for an Amiga or DraCo or the VME
: multiprocessor modules in my lab, using the optimal O40-or-better
: insns (dcas? mov16?).  I haven't changed the ``default'' for that
: toolchain, but I've built an entire luserland that needs an 040/060.

See below.  This is not the same argument.

: Todd, if I understand this right, you're saying the following
: are all the same:
: 	a. ``executabillity'' of output of a toolchian with
: 		default switches.
: 	b. ${MACHINE_ARCH~}
: 	c.  uname -m

: In any case I think it's a bogus definition, since it assumes we have
: a lowest-common-denominator and that's what people always use.  But in
: practice, they don't.

It doesn't matter what people always use:  it matters that the least common
denominator, the default toolchain output of a MACHINE_ARCH, is consistent
and runs on a given MACHINE_ARCH.

: You assume a tight identity between "will this run"?  and
: $MACHINE_ARCH, but that just doesn't exist.

It exists, and is being used in

- GNU autoconf
- pkgs (documented, and tightly used)

and should be used in

- cross compiling the tree (which I've been working on)
- multiple-target toolchains (to choose the default)

: 	1. mips binaries have separate, independent flags for indicating
: 	     a) "uses mips1 insns" vs "uses mips3 insns"
: 	     b) "uses 32-bit addressing" vs "uses 64-bit addressing"
: 	2. The kernel refuses to run mips3/32-bit binaries on a mips1
:    	   CPU.
: 
: I dont see how that is so different from tags in a binary which say
: "mipsel" or "mipseb". Which they do.

Can you run a 32-bit MIPS binary with a 64-bit shared libc?  Vice versa?

In your example at top, you could certainly run an 040-compiled binary with
an 020-compiled libc, and vice versa (as long as your processor supported
040 insns).  I doubt you can mix wordsizes in the same way, and I _know_ you
cannot mix endianness in the same way.

The difference is a fundamental difference in the interpretation of how
numbers work.  In a 64-bit world, pointers are twice the size as in a 32-bit
world.  In a little-endian world, bytes are reversed from a big-endian
world.  In a 68040 world, there's no difference in basic types from a
68020 world.

Different wordsizes and different endiannesses are completely incompatible
formats.  Though there are ways to run many "foreign" binaries (as have
already been brought up), that's still _emulation_, not native
execution--you have to supply the foreign shared loader, libc, and probably
a host of other things depending on the program.

: Did you say this "promise" was documemented somewhere?

The only NetBSD documentation I've found so far is the pkg system - and it
definitively shows a direct link between MACHINE_ARCH and binary
compatibility.

I'm still looking, and perhaps I won't find others.  Is there any
documentation to say that there _isn't_ such a link?

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)