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
