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 +
