Todd Vierling writes:

On Thu, 23 Jul 1998, Todd Vierling wrote:

: : >MACHINE_ARCH SHOULD SPECIFY A COMPATIBLE SET OF BINARIES, AND IS DOCU
MENTED
: : >TO DO SO.  That's a far more long-standing promise than the mips plat
forms
: : >have even existed.


The person who designed that ``promise'' didnt' think about bi-endian
machines at the time.  It was discussed again in April.  The decision
was not to split ${MACHINE_ARCH}.  CGD and Jason Thorpe concurred.
I see a couple of messages from you in the thread, even.



: : Nobody disagrees that we need to distinguish both MACHINE_ARCH and
: : MACHINE_ARCH_ENDIAN (or whatever it ends up being called).

>OK... Either everyone went on vacation, or the only _dissenter_ that I can
>see to my proposal to modify the valuse of "mips" for LE and BE machines
>that I see thinks the problem has been `solved' and I went away.

I think it's that your propposal doesn't really solve the problems of
having support for bi-endian CPUs in the tree. Leaving $MACHINE_ARCH
alone and fixing the places that do need to care about endian-ness
seems a better solution.

>I still haven't heard what keeping both little-endian and big-endian
>architectures under one MACHINE_ARCH gains the developer and user beyond
>slightly simpler organization of include and main tree source files.

Because we decided it's the right thing to do?

Splitting $MACHINE_ARCH doesn't buy much except someone who can't
write the sh code to figure out the internal GCC machine/arch
identifier, or installing binary packages, or finding install sets.
Those we'd have to change anyway.

Having ${MACHINE_ARCH} == "mips" determines at least as many other
things. Whatever way we jump breaks something, but I think this breaks
less.


>I also still haven't heard why using more than one value to identify a
>compatible set of binaries is better than using only one, and why breaking
>existing promises of compatibility is better than keeping them.


Because that promise got changed?
(And I'm curious too to see where and by who it's documented, too).

>Oh, and can someone run `uname -m' on an ULTRIX, OSF/1, and Digital UNIX b
>ox
>on a mips processor and verify what it prints?  Also, if anyone can verify
>the output of `uname -m' on NeWS stations running NeWS-OS (I believe they
>ha

RISC ULTRIX says RISC.  OSF/1 on mips existed but I dont know if it
formally shipped.  DU didn't ship.