On Sun, May 19, 2002 at 11:05:52PM -0700, Matthew Dharm wrote: > > > What does it take to do a 64-bit port? The first problem I see is the > > > boot loader -- do I have to be in 64-bit mode when the kernel starts, > > > or can I start in 32-bit mode and then transfer to 64-bit mode? > > > > Same loader as before - the build procedure will result in a 32-bit kernel > > binary which is loaded to the same old KSEG0 addresses. > > Call me a bit slow, but... > > Are you saying that my 32-bit loader (which is designed to load a 32-bit > ELF file) will do exactly that... but this 32-bit ELF file has the magic in > it to switch to 64-bit internally? > > Nice... Very nice. I'm used to slick Open Source solutions, but I have to > admit that this is a pretty elegant one that solves a great many > problems... It's a fairly natural solution to the problem we had. The scenario we had to deal with was - a machine (SGI Origin 200/2000 aka IP27) where configurations are commonly way too large for a 32-bit kernel. - 64-bit MIPS/ELF support that was close to entierly unusable - fixing binutils fully would have taken a serious amount of time which we didn't have. As it turned out gas is perfectly able to assemble the assembler code that is generated for the N64 ABI by gcc into 32-bit ELF and linking that. That code model still uses 64-bit pointers just all intra-kernel refernces that were generated from la or dla macros get expanded into just the two instruction sequence for 32-bit code, not the upto 7 instruction used for 64-bit code. Result: much less tools work necessary yet better code. Ralf
