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

There's a separate version of the floppy disk driver because nobody's
had the time to make it generic and move it into sys/dev/sun.
Volunteers? 8^)

Most of the header files differ.  The trap model is different.  The
register map is different.  The MMU is different.  The bus controllers
are different.  The address spaces are different.  The instruction set
is different.  The PROM is different.  Stack frames are different.
This means that the pcb is different, the trapframes are different,
practially all of locore.s is different.  All of pmap is different.

The only thing that's really the same between the two architectures is
that SPARC v9 is able to execute legacy SPARC binaries if properly
initialized.

From what I know about MIPS, the only major changes between 32-bit and
64-bit are the load/store instructions and the TTEs.  Traps are pretty
much the same, and the way the MMU handles translated and direct
addresses is pretty much the same.

I suppose more sharing could go on between sparc and sparc64.  The
problem is maintenance.  You need to be able to test changes for
breakage on both architectures to make a merger manageable.  That's
simply not possible at the moment.