On Tue, Jul 22, 2003 at 11:37:44PM +0200, Maciej W. Rozycki wrote: > > 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. You're right, we've got a good bit of assembler code that should just be C. So I rewrote some of the code to C. > 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? Not intend to change the behaviour of uname. It actually changed in CVS, for now consider that a bug ... We should consider changing the behaviour though. A machine type of mips64 broke lots of software. Of course that was all 32-bit softare but it raises the question if returning mips64 is really a good idea? As for choosing a 32-bit vs. 64-bit kernel, that's now a menu point and can be choosen like every other config option. Ralf
