public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Matt Thomas <jabbathespud@gmail.com>
To: David Daney <ddaney@caviumnetworks.com>
Cc: GCC <gcc@gcc.gnu.org>, binutils <binutils@sourceware.org>,
	Prasun Kapoor <prasun.kapoor@caviumnetworks.com>
Subject: Re: RFC: A new MIPS64 ABI
Date: Tue, 15 Feb 2011 02:35:00 -0000	[thread overview]
Message-ID: <84F21E9B-D512-40CD-97C3-29CABF7E42B6@3am-software.com> (raw)
In-Reply-To: <4D59E44F.6010807@caviumnetworks.com>


On Feb 14, 2011, at 6:26 PM, David Daney wrote:

> On 02/14/2011 06:14 PM, Joe Buck wrote:
>> 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).
>> 
> 
> Also look at the new x86_64 ABI (See all those X32 psABI messages) that the Intel folks are actively working on.  This proposal is very similar to what they are doing.

untrue.  N32 is closer to the X32 ABI since it is limited to 2GB.

  reply	other threads:[~2011-02-15  2:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-14 20:29 David Daney
2011-02-15  0:15 ` Matt Thomas
2011-02-15  1:57   ` Paul Koning
2011-02-15  2:15     ` Joe Buck
2011-02-15  2:16       ` Paul Koning
2011-02-15  2:26       ` David Daney
2011-02-15  2:35         ` Matt Thomas [this message]
2011-02-15  2:43           ` David Daney
2011-02-15 17:33       ` Joseph S. Myers
2011-02-15 18:15         ` David Daney
2011-02-15  2:22   ` David Daney
2011-02-15  2:33     ` Matt Thomas
2011-02-15  2:50       ` David Daney
2011-02-15  3:02         ` Matt Thomas
2011-02-15 17:41           ` David Daney
2011-02-15 17:48             ` Paul Koning
2011-02-15 17:56 ` Alexandre Oliva
2011-02-15 18:08   ` David Daney
2011-05-06  8:31     ` Alexandre Oliva
2011-05-06 17:00       ` David Daney
2011-02-18  1:02 ` David Daney
     [not found] <4D5990A4.2050308__41923.1521235362$1297715435$gmane$org@caviumnetworks.com>
2011-02-21 19:45 ` Richard Sandiford
2011-05-09 14:27   ` Ralf Baechle
2011-05-09 17:47     ` David Daney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84F21E9B-D512-40CD-97C3-29CABF7E42B6@3am-software.com \
    --to=jabbathespud@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=ddaney@caviumnetworks.com \
    --cc=gcc@gcc.gnu.org \
    --cc=prasun.kapoor@caviumnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).