linux-mips-fnet
[Top] [All Lists]

Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64
From: "Kevin D. Kissell" <kevink@mips.com>
Date: Tue, 23 Jul 2002 14:13:10 -0700
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle <ralf@uni-koblenz.de>
Organization: MIPS Technologies Inc.
References: <Pine.GSO.3.96.1020723164235.29699A-100000@delta.ds2.pg.gda.pl>
Sender: kevink@mips.com
> > My personal belief is that the mips and mips64 trees
> > should ultimately be merged, and that creating additional
> > and gratuitous differences should be avoided.
> 
>  I don't think it's possible to be fully achieved.  Some differences will
> have to exist, at least in the headers, but likely within the arch tree as
> well.  The reason is binary code size or perfomance -- having R3000
> support code in mips64 binaries is simply ridiculous as is using 32-bit
> operations with 64-bit data on a 64-bit CPU.  However, it is worth trying
> to minimize visible differences where possible, e.g. by convincing the
> compiler to optimize irrelevant bits away.

I am not interested in running R3000's with 64-bit
binaries - only in having common sources for both.
I fully expect that there will always be differences
between the platforms, but the last time I checked,
there were more identical or nearly identical source
modules across the two arch trees than there were 
distinctly different ones.  The result is that the 
two subtrees tend to drift out of sync.  For me, 
it's really a "Software Engineering 101" kind of 
thing that there should be exactly one instance 
in the source tree of any source module that is 
common to 32-bit and 64-bit MIPS kernels, and that 
where the code cannot be common, sensible rules should 
be applied in terms of when to put both sets of code 
in the same module as conditionally complied blocks and
when to split things out into seperately maintained
modules. Etc. Etc.

                Kevin K.

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