From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 903 invoked by alias); 15 Feb 2011 17:41:56 -0000 Received: (qmail 894 invoked by uid 22791); 15 Feb 2011 17:41:56 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp2.caviumnetworks.com (HELO smtp2.caviumnetworks.com) (209.113.159.134) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Feb 2011 17:41:51 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by smtp2.caviumnetworks.com with MailMarshal (v6,7,2,8378) id ; Tue, 15 Feb 2011 12:41:55 -0500 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 09:41:48 -0800 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 09:41:48 -0800 Message-ID: <4D5ABAD7.6030901@caviumnetworks.com> Date: Tue, 15 Feb 2011 17:41:00 -0000 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Matt Thomas CC: GCC , binutils , Prasun Kapoor Subject: Re: RFC: A new MIPS64 ABI References: <4D5990A4.2050308@caviumnetworks.com> <4D59E355.9050407@caviumnetworks.com> <4D59E9E1.5080405@caviumnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00173.txt.bz2 On 02/14/2011 07:00 PM, Matt Thomas wrote: > > On Feb 14, 2011, at 6:50 PM, David Daney wrote: > >> On 02/14/2011 06:33 PM, Matt Thomas wrote: >>> >>> On Feb 14, 2011, at 6:22 PM, David Daney wrote: >>> >>>> On 02/14/2011 04:15 PM, Matt Thomas wrote: >>>>> >>>>> 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. >>> >>> N32 doesn't require a LP64 kernel, just a 64-bit register aware kernel. >>> Your N32-big does require a LP64 kernel. >>> >> >> But using 'official' kernel sources the only way to get a 64-bit register aware kernel is for it to also be LP64. So effectively, you do in fact need a 64-bit kernel to run n32 userspace code. > > Not all the world is Linux. :) NetBSD supports N32 kernels. > Use of LP32 in the kernel is only really appropiate in systems with a small amount of memory. The proposed n32-big would run on such systems, but would probably *not* have an advantage over standard n32. >> My proposed ABI would need trivial kernel changes: >> >> o Fix a couple of places where pointers are sign extended instead of zero extended. > > I think you'll find there are more of these than you'd expect. You could be right, but to date in auditing the Linux kernel, sigaction() is the only place I have found. > >> o Change the stack address and address ranges returned by mmap(). > > My biggest concern is that many many mips opcodes expect properly > sign-extended value for registers. Thusly N32-big will require > using daddu/dadd/dsub/dsubu for addresses. So that's yet another > departure from N32 which can use addu/add/sub/subu. That's right. Which is why I said... > >> The main work would be in the compiler toolchain and runtime libraries. > > You'd also need to update gas for la and dla expansion. > I am counting gas, ld and libc as part of the 'compiler toolchain' David Daney