Re: RFC: A new MIPS64 ABI

[Paul Koning <paul_koning@dell.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