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.