>: Even worse is the option (which someone comes up with every 6 months)
>: to use 32-bit ints and pointers, but to set the FPU into 64-bit mode.
>: That doubles the number of FP registers and may increase memory
>: bandwidth.   Is that yet another kind of ${MACHINE_ARCH}?

>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.

Oh, nonsense.  if I compile up an entire alpha userland which uses the
byte load/store instructions, it'll run on an EV5 but not an EV4 (or
whatever the right designation is.  I haven't changed the ``default''
switches at all, but I've created an ``incompatible'' userland.

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.

If I try and run those binaries on an 020, the kernel should figure
out that it can't run them based on CPU-id tags -- like the sun2 to
sun3 migration.

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

can you show me where that `promise' was consciously made and
documented (rather than simply being assumed) in a way that isn't
violated by the email I forwarded to you?

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.

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


And for the record, on pmax (and arc), we support the same
semantics as Ultrix:

	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.



Again:

>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.

Did you say this "promise" was documemented somewhere?