Date: Sat, 13 Jul 2013 08:26:56 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note Message-ID: <51E155A0.6030409@freebsd.org> In-Reply-To: <CAJ-Vmo=HoTRBXnJXeVT7dDW-kHLpQCiB4PFya97P5_5oD5Xx6A@mail.gmail.com> References: <F79E2F76-A234-499A-ABB7-1ABA62283E9D@FreeBSD.org> <51E06B85.10109@pix.net> <CAJ-Vmo=HoTRBXnJXeVT7dDW-kHLpQCiB4PFya97P5_5oD5Xx6A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/12/13 18:02, Adrian Chadd wrote: > On 12 July 2013 13:48, Kurt Lidl <lidl@pix.net> wrote: >>> It seems to be driven by Intel and Google. The idea is that for some >>> applications (or maybe even most :), an ILP32 model will perform better. >> >> I believe that Google's NaCl (native client) plugins for Chrome all use >> the "x32" ABI. The NaCl stuff uses this, along with a "safe" code >> generation path to implement part of the sandboxing for Chrome plugins. >> >> Ultimately, to have a fully functioning Chrome (with plugins) on amd64 >> hosts, we'll want to support "x32". > Does this mean that netbooks with only 32 bit CPUs in them won't support NaCl? > (Ie, they're only ever going to generate x32 code, and even 32 bit > machines will still run 64 bit assembly..) > As I remember, they are trying to have a constant ABI (32-bit pointers, little endian) irrespective of the actual architecture to make things really just a recompile. Basically, it's meant to be something where sizeof(everything) is the same both on x86 and little-endian ARM. So this means there is 32-bit x86 and x32, but not amd64. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51E155A0.6030409>