linux-mips
[Top] [All Lists]

Re: CVS Update@-mips.org: linux

To: Keith M Wesolowski <wesolows@foobazco.org>
Subject: Re: CVS Update@-mips.org: linux
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Tue, 22 Jul 2003 21:39:40 +0200 (MET DST)
Cc: "Kevin D. Kissell" <kevink@mips.com>, ralf@linux-mips.org, linux-mips@linux-mips.org
In-reply-to: <20030721182002.GA28587@foobazco.org>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
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        +


<Prev in Thread] Current Thread [Next in Thread>