This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: A new MIPS64 ABI
- From: Paul Koning <paul_koning at dell dot com>
- To: Matt Thomas <jabbathespud at gmail dot com>
- Cc: David Daney <ddaney at caviumnetworks dot com>, GCC <gcc at gcc dot gnu dot org>, binutils <binutils at sourceware dot org>, Prasun Kapoor <prasun dot kapoor at caviumnetworks dot com>
- Date: Mon, 14 Feb 2011 20:57:13 -0500
- Subject: Re: RFC: A new MIPS64 ABI
- References: <4D5990A4.2050308@caviumnetworks.com> <B54F2940-13D7-4B64-AD1B-C81CC37BA857@3am-software.com>
On Feb 14, 2011, at 7:15 PM, Matt Thomas wrote:
>
> On Feb 14, 2011, at 12:29 PM, David Daney wrote:
>
>> Background:
>>
>> Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
>> user virtual memory space. This is due the way MIPS32 memory space is
>> segmented. Only the range from 0..2^31-1 is available. Pointer
>> values are always sign extended.
>>
>> Because there are not already enough MIPS ABIs, I present the ...
>>
>> Proposal: A new ABI to support 4GB of address space with 32-bit
>> pointers....
>
> 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.
It seems a very large amount of work for a very small benefit.
>
>> At a low level here is how it would work:
>>
>> 1) Load a pointer to a register from memory:
>>
>> n32:
>> LW $reg, offset($reg)
>>
>> n32-big:
>> LWU $reg, offset($reg)
>
>
> That might be sufficient for userland, but the kernel will need
> to do similar things (even if a 64bit kernel) when accessing
> structures supplied by 32-bit syscalls.
Right, which creates amazing opportunities for bugs.
>
> It seems to be workable but if you need the additional address space
> why not use N64?
It seems that this proposal would benefit programs that need more than 2 GB but less than 4 GB, and for some reason really don't want 64 bit pointers.
This seems like a microscopically small market segment. I can't see any sense in such an effort.
paul