This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: A new MIPS64 ABI

On 02/14/2011 04:15 PM, Matt Thomas wrote:

On Feb 14, 2011, at 12:29 PM, David Daney wrote:


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

The proposed new ABI would only be available on MIPS64 platforms.  It
would be identical to the current MIPS n32 ABI *except* that pointers
would be zero-extended rather than sign-extended when resident in
registers.  In the remainder of this document I will call it
'n32-big'.  As a result, applications would have access to a full 4GB
of virtual address space.  The operating environment would be
configured such that the entire lower 4GB of the virtual address space
was available to the program.

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.

At a low level here is how it would work:

1) Load a pointer to a register from memory:

	LW $reg, offset($reg)

	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.

It is a userspace ABI. The MIPS64 kernel already uses something similar (the -msym32 option). There would be no change to the kernel.

It seems to be workable but if you need the additional address space
why not use N64?

In n64 pointers are 64-bits wide. Programs that use many pointer laden data structures have a much larger cache/memory footprint than their n32 versions.

Also the number of instructions required to load a 64-bit constant is much larger than that needed to load a 32-bit constant.

David Daney

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]