Subject: re: IMPORTANT: MACHINE_ARCH WRONG ON MIPS PLATFORMS
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Todd Vierling <tv@pobox.com>
List: port-mips
Date: 07/23/1998 16:38:11
On Thu, 23 Jul 1998, Jonathan Stone wrote:

: Please think through this. I think MACHINE_ARCH == mips is a better
: decision. not going to change my mind by repeating the same arugments.
: 
: mipsel vs mipseb is no bigger a deal than mips32 vs mips64.  THink
: about it.  should those show up as different kinds of $MACHINE_ARCH
: too?

Yes, unless it has the same binary sets.

The MACHINE for sparc64 is sparc64, but the MACHINE_ARCH is sparc, becasue
the binary format is the same unless you're using V9 instructions (similar
to using 68060 instructions on m68k) - 32-bit a.out, SPARC V8 big-endian by
default.

: My take is that $MACHINE_ARCH used to lump together two concepts: both
: ``mips'' (all endianness vs, say, ``m68k'' and `mipseb'' versus ``mipsel''
: (and soon mips64 vs mips32?).  

If mips64 will require a different binary format, it to should be a
different MACHINE_ARCH as well.

: But there are still a lot of meaningful distinctions that get made
: based on purely the _architecture_: e.g, in building set-list entries
: which depend on the fact that a machine is a "mips", irrespective of
: endian-ness.

This works only because we _happen_ to use the same basic toolchain format
(ELF) on mipsel and mipseb.  If one of them were still a.out, this rgument
would go out the window.

: We need to have two levels of distinction. That much everyone agrees on. 
: I'm saying it makes more sense to leave MACHINE_ARCH==mips alone, and
: introduce a new way to name and specify the endian-ness.  And (as best
: I recall) that was also the final decision last time it came up.  OK?

Pkgs care less about endianness.  Third party software cres less about
endianness.

MACHINE_ARCH SHOULD SPECIFY A COMPATIBLE SET OF BINARIES, AND IS DOCUMENTED
TO DO SO.  That's a far more long-standing promise than the mips platforms
have even existed.

MIPS is broken.

: >we're using it now, and we probably will continue to be using it
: >that way.   The existing state is breaking that promise that MACHINE_ARCH
: >gives.
: 
: No, as best I recall, we changed the promise.

Then why does the pkg system rely on the same promise?  Why does GNU
software?

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