On 02/14/2011 07:00 PM, Matt Thomas wrote:
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.
Use of LP32 in the kernel is only really appropiate in systems with a
small amount of memory. The proposed n32-big would run on such systems,
but would probably *not* have an advantage over standard n32.
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.
You could be right, but to date in auditing the Linux kernel,
sigaction() is the only place I have found.
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.
That's right. Which is why I said...
The main work would be in the compiler toolchain and runtime libraries.
You'd also need to update gas for la and dla expansion.
I am counting gas, ld and libc as part of the 'compiler toolchain'
David Daney
