RFC: A new MIPS64 ABI

[David Daney]

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