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