On Mon, 21 Jul 2003, Keith M Wesolowski wrote:
> sparc32 and sparc64 processors and systems are significantly
> different. For example, the SRMMU present in v8 CPUs is 100% replaced
> with a totally different MMU (indeed, totally different instructions,
> access methods, etc) in v9. Accordingly there is very little code in
> common between the two ports, and most of that is in device handling;
> code that is in drivers/sbus and thus shared anyway.
Well, the MMU of (original) 32-bit MIPS processors (i.e. R2k/R3k) is
completely different from the one in later ones, too. I suspect this is
true for the R6k as well. The exception handlers differ a bit as well,
especially considering the XTLB refill one. That probably counts as
nitpicking, though...
> Something that made sense for sparc might not make sense for mips.
Certainly it needs to be analysed on a case by case basis, avoiding
blanket assumptions. Anyway, I still see two reasons for having at least
a separate top-level directory:
1. A better separation of the more straightforward 32-bit Makefile and the
more complicated 64-bit one.
2. A better visual existence of the 64-bit port; not really a technical
advantage, but more a psychological one. It stops any newcomer wondering
whether we support 64-bit systems natively or not.
There is also no point in having headers in asm-mips consisting of a
single #ifdef CONFIG_MIPS32/#else/#endif conditional, where two distinct
versions should be present in asm-mips and asm-mips64, respectively. It's
easier to make a diff between such separate implementations to verify
everything's OK.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|