On Tue, 22 Jul 2003, Ralf Baechle wrote:
> And yes, the R6000 is different. With that in mind R2000 and R4000 look
> like enzygotic twins ...
;-)
> > 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.
>
> I was thinking about that also. arch/mips64 and include/asm-mips64 will
> go away but on the other side there will be an option to configure a
> 64-bit kernel in the menus - which will hopefully be more visible than
> just two subdirectories.
Well, as long as one get that far to run a configuration script (BTW,
what menus are you referring to? -- I haven't seen any). Right now that's
easily visible straight in the archive which is now even browsable in the
Internet here and there -- Q: "What architectures are supported?" A: "See
the subdirectories of arch/."
> Btw, an old experience repeats - some of the code was identical except
> inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
> I rewrote that stuff to use C for this arithmetic. The result - less
> inline assembler, more readable code and a file that's identical for
> both 32-bit and 64-bit.
Well, whatever is plain C code (or should be such) should be identical,
indeed, but macros will differ as will low-level assembly. Then add
64-bit specific options and you get yet more complication.
I hope `uname -m' will continue to report the correct architecture and
that ARCH will be correctly handled (i.e. "mips" selecting a 32-bit build
and "mips64" a 64-bit one) -- have you considered this?
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|