Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com,
	Ralf Baechle <ralf@uni-koblenz.de>
Subject: Re: [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64
Date: Tue, 23 Jul 2002 14:13:10 -0700	[thread overview]
Message-ID: <3D3DC6E6.AFF9CBFD@mips.com> (raw)
In-Reply-To: Pine.GSO.3.96.1020723164235.29699A-100000@delta.ds2.pg.gda.pl

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

  reply	other threads:[~2002-07-23 21:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-23 11:55 [patch] linux: cpu_probe(): remove 32-bit CPU bits for MIPS64 Maciej W. Rozycki
2002-07-23 12:14 ` Ralf Baechle
2002-07-23 13:05   ` Maciej W. Rozycki
2002-07-23 13:23     ` Ralf Baechle
2002-07-23 13:31       ` Maciej W. Rozycki
2002-07-23 13:59         ` Ralf Baechle
2002-07-23 18:20     ` Jun Sun
2002-07-24 15:11       ` Maciej W. Rozycki
2002-07-23 14:38 ` Kevin D. Kissell
2002-07-23 14:38   ` Kevin D. Kissell
2002-07-23 14:49   ` Ralf Baechle
2002-07-23 16:00   ` Maciej W. Rozycki
2002-07-23 21:13     ` Kevin D. Kissell [this message]
2002-07-24 14:52       ` Ralf Baechle
2002-07-24 15:05         ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D3DC6E6.AFF9CBFD@mips.com \
    --to=kevink@mips.com \
    --cc=linux-mips@fnet.fr \
    --cc=linux-mips@oss.sgi.com \
    --cc=macro@ds2.pg.gda.pl \
    --cc=ralf@uni-koblenz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox