linux-mips
[Top] [All Lists]

Re: RFC: A new MIPS64 ABI

To: David Daney <ddaney@caviumnetworks.com>
Subject: Re: RFC: A new MIPS64 ABI
From: Alexandre Oliva <aoliva@redhat.com>
Date: Tue, 15 Feb 2011 15:56:01 -0200
Cc: linux-mips <linux-mips@linux-mips.org>, GCC <gcc@gcc.gnu.org>, binutils <binutils@sourceware.org>, Prasun Kapoor <prasun.kapoor@caviumnetworks.com>
In-reply-to: <4D5990A4.2050308@caviumnetworks.com> (David Daney's message of "Mon, 14 Feb 2011 12:29:24 -0800")
Organization: Free thinker, does not speak for Red Hat or its Operating System Tools Group
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4D5990A4.2050308@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
On Feb 14, 2011, David Daney <ddaney@caviumnetworks.com> 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.

> 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.

FTR, I don't really know why my Yeeloong is limited to 31-bit addresses,
and I kind of hoped an n32 userland would improve that WRT o32, without
wasting memory with longer pointers like n64 would.

So, sorry if this is a dumb question, but wouldn't it be much easier to
keep on using sign-extended addresses, and just make sure the kernel
never allocates a virtual memory range that crosses a sign-bit change,
or whatever other reason there is for addresses to be limited to the
positive 2GB range in n32?

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

<Prev in Thread] Current Thread [Next in Thread>