From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14415 invoked by alias); 15 Feb 2011 00:15:29 -0000 Received: (qmail 14388 invoked by uid 22791); 15 Feb 2011 00:15:25 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Feb 2011 00:15:21 +0000 Received: by iyi20 with SMTP id 20so5918015iyi.0 for ; Mon, 14 Feb 2011 16:15:18 -0800 (PST) Received: by 10.42.217.195 with SMTP id hn3mr5707268icb.332.1297728918637; Mon, 14 Feb 2011 16:15:18 -0800 (PST) Received: from bookie.home (75-25-129-194.lightspeed.sjcpca.sbcglobal.net [75.25.129.194]) by mx.google.com with ESMTPS id i2sm2726023icv.3.2011.02.14.16.15.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 16:15:16 -0800 (PST) Subject: Re: RFC: A new MIPS64 ABI Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Matt Thomas In-Reply-To: <4D5990A4.2050308@caviumnetworks.com> Date: Tue, 15 Feb 2011 00:15:00 -0000 Cc: GCC , binutils , Prasun Kapoor Content-Transfer-Encoding: 7bit Message-Id: References: <4D5990A4.2050308@caviumnetworks.com> To: David Daney Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00148.txt.bz2 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. > > 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. > 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. It seems to be workable but if you need the additional address space why not use N64?