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 +
