On Feb 14, 2011, at 6:50 PM, David Daney wrote: > On 02/14/2011 06:33 PM, Matt Thomas wrote: >> >> On Feb 14, 2011, at 6:22 PM, David Daney wrote: >> >>> On 02/14/2011 04:15 PM, Matt Thomas wrote: >>>> >>>> I have to wonder if it's worth the effort. The primary problem I see >>>> is that this new ABI requires a 64bit kernel since faults through the >>>> upper 2G will go through the XTLB miss exception vector. >>>> >>> >>> Yes, that is correct. It is a 64-bit ABI, and like the existing n32 ABI >>> requires a 64-bit kernel. >> >> N32 doesn't require a LP64 kernel, just a 64-bit register aware kernel. >> Your N32-big does require a LP64 kernel. >> > > But using 'official' kernel sources the only way to get a 64-bit register > aware kernel is for it to also be LP64. So effectively, you do in fact need > a 64-bit kernel to run n32 userspace code.
Not all the world is Linux. :) NetBSD supports N32 kernels. > My proposed ABI would need trivial kernel changes: > > o Fix a couple of places where pointers are sign extended instead of zero > extended. I think you'll find there are more of these than you'd expect. > o Change the stack address and address ranges returned by mmap(). My biggest concern is that many many mips opcodes expect properly sign-extended value for registers. Thusly N32-big will require using daddu/dadd/dsub/dsubu for addresses. So that's yet another departure from N32 which can use addu/add/sub/subu. > The main work would be in the compiler toolchain and runtime libraries. You'd also need to update gas for la and dla expansion.
