[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.21.1811302309530.25979@eddie.linux-mips.org>
Date: Fri, 30 Nov 2018 23:25:09 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...ux-mips.org>
To: Bernd Petrovitsch <bernd@...rovitsch.priv.at>
cc: Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>,
Tycho Andersen <tycho@...ho.ws>,
Daniel Colascione <dancol@...gle.com>,
Florian Weimer <fweimer@...hat.com>,
Carlos O'Donell <carlos@...hat.com>,
Rich Felker <dalias@...c.org>
Subject: Re: Cleaning up numbering for new x86 syscalls?
On Wed, 21 Nov 2018, Bernd Petrovitsch wrote:
> And yes, lots of stuff will not compile out of the box (especially if
> one uses a somewhat sane set of gcc options - not only -Wall -Wextra
> -Werror) but if one gets software to compile for i386 and x86_64,
> getting it to compile for x32 is a Friday afternoon job (more or less).
> And yes, there is enough hardware/systems out there that uses 64bit CPUs
> (for whatever reason - if only that one can't get a 32bit CPU for that
> board) but will never ever need more than 2-3 GB RAM .....
The functionally equivalent 64-bit ILP32 MIPS n32 ABI has been around
supported by Linux and the GNU toolchain for some 17 years now and people
have been using it, so by now any sane piece of software that does not use
handcoded assembly should work out of the box for the x86-64 x32 ABI as
well.
NB the important advantage of an LP64 ABI over an ILP32 ABI is the
ability to mmap(2) files that exceed 4GiB in size (and in reality even
smaller ones, as some user VM space is surely needed for other stuff),
regardless of how much physical RAM is actually supported or has been
installed.
And these days even a web browser can easily overrun a 4GiB VM space. :(
FWIW,
Maciej
Powered by blists - more mailing lists