From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28215 invoked by alias); 15 Feb 2011 02:15:05 -0000 Received: (qmail 28199 invoked by uid 22791); 15 Feb 2011 02:15:04 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from us02smtp2.synopsys.com (HELO alvesta.synopsys.com) (198.182.60.77) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Feb 2011 02:14:57 +0000 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by alvesta.synopsys.com (Postfix) with ESMTP id 69B442062; Mon, 14 Feb 2011 18:14:56 -0800 (PST) Received: from godel.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id SAA09982; Mon, 14 Feb 2011 18:14:55 -0800 (PST) Received: from godel.synopsys.com (localhost [127.0.0.1]) by godel.synopsys.com (8.13.1/8.12.3) with ESMTP id p1F2Etnx001840; Mon, 14 Feb 2011 18:14:55 -0800 Received: (from jbuck@localhost) by godel.synopsys.com (8.13.1/8.13.1/Submit) id p1F2Ektk001839; Mon, 14 Feb 2011 18:14:46 -0800 Date: Tue, 15 Feb 2011 02:15:00 -0000 From: Joe Buck To: Paul Koning Cc: Matt Thomas , David Daney , GCC , binutils , Prasun Kapoor Subject: Re: RFC: A new MIPS64 ABI Message-ID: <20110215021446.GE29824@synopsys.com> References: <4D5990A4.2050308@caviumnetworks.com> <139B199E-0408-4F99-878C-D7063D607497@dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <139B199E-0408-4F99-878C-D7063D607497@dell.com> User-Agent: Mutt/1.4.1i 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/msg00150.txt.bz2 On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: > 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. I remember the RHEL hugemem patch being a big deal for lots of their customers, so a process could address the full 4GB instead of only 3GB on a 32-bit machine. If I recall correctly, upstream didn't want it (get a 64-bit machine!) but lots of paying customers clamored for it. (I personally don't have an opinion on whether it's worth bothering with).