"Eduardo E. Horvath" <eeh@one-o.com> writes:

>On Sat, 25 Jul 1998, Jonathan Stone wrote:

>> Worse, what happens when we go to 64-bit mips and have four arches to
>> support, instead of two?  ``it doesn't make sense to me''.

>I don't know.  What does happen whe you go to 64-bit mips?
>
>AFIK the current model of MACHINE and MACHINE_ARCH doesn't work very well
>where one architecture is a superset of another atchitecture.  A mips64
>machine should be able to run mips32 binaries, but not the other way
>around.  So what happens?  Does MACHINE_ARCH become `mips' and `mips64'
>and the two are wholely incompatible?  Does a mips64 machine use a mips32
>userland?

I dont know either.  I honeslty dont see -le vs -be as that much
different from 64 vs 32.  Todd says they're the same ${MACHINE_ARCH},
even tho' strictly they aren't always supersets.  (pedantically,
m68020 to 040 isn't a superset: some insns are emulated, and there are
some 020 insns which arent emulated but nobody ever really used.  and
if you generate tuned 040 code using 040-only insns, it wont run on an
020. Same for mips3 with squashed branches, etc.)


Plus if you really want native 64-bit binaries, they arent going to
run on a v8 sparc. So by that definition, sparc64 should be a seperate
${MACHINE_ARCH}. yes?


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}?