In message <87d7oqysyz.fsf@redmail.netbsd.org>Chris G. Demetriou writes
>Simon Burge <simonb@netbsd.org> writes:

>similarly here.  i don't think sparc should include sparc64.  maybe
>sparc64 including sparc is OK -- i dunno, but even that doesn't seem
>to make much sense to me.  the only thing that should be included
>multiple times are the basic CPU support dirs which support multiple
>endiannesses (e.g. mips).

I lost you. are you saying mips does it nearly right, or not?  Note
that mips doesnt do mips64 (yet) and observations that the hacks in our
current Makefiles wouldn't scale to mips{eb,el}{,64} were roundly
ignored.

Maybe endian-ness just isn't that big a deal compared to supporting
64-bit addresses everywhere they have to be?

>(as an aside, i've kinda wondered: why can't sparc and sparc64 be put
>in the same MACHINE_ARCH, in the same way that all of the various MIPS
>flavors are.  there's similar variation between mips32 and mip64,
>right?  I'd expect the same ABI issues to show up in each place, and
>i'd expect a consistent solution, but my expectations aren't often in
>sync with reality.  8-)

I dont know. I never understood why sparc64 needed, say, its own
version of the floppy-disc controler, let alone all the header files.