[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.1102131729120.16193@digraph.polyomino.org.uk>
Date: Sun, 13 Feb 2011 17:37:50 +0000 (UTC)
From: "Joseph S. Myers" <joseph@...esourcery.com>
To: Petr Baudis <pasky@...e.cz>
cc: "H.J. Lu" <hjl.tools@...il.com>, Florian Weimer <fw@...eb.enyo.de>,
x32-abi@...glegroups.com, GCC Development <gcc@....gnu.org>,
GNU C Library <libc-alpha@...rceware.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: X32 psABI status
On Sun, 13 Feb 2011, Petr Baudis wrote:
> I think it would be great if you could add some text like this plus some
> rationale (AIUI, this is geared mainly at new Atoms and other x86_64
> embedded platforms) to the document.
>
> (BTW, it is not really convincing to me that such a niche is worth all
> the trouble this is going to bring.)
It seems to me there's a much more general utility for this. After all,
the normal practice on 64-bit Power Architecture GNU/Linux systems, say,
is for most programs to be 32-bit and only a few that have a use for a
large address space to be 64-bit. For most programs, large pointers and
size_t are just a waste of memory (and so of cache) - but the extra
registers are significantly beneficial (as are such things as being able
to assume SSE to be supported). (Large files, 64-bit time_t, etc.,
however, are of wider use than large address space, but as I noted in
<http://gcc.gnu.org/ml/gcc/2010-12/msg00509.html> it would be a fairly
substantial project to address all such issues of inappropriate arbitrary
limits in C APIs.)
--
Joseph S. Myers
joseph@...esourcery.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists