Date: Fri, 12 Jul 2013 23:05:11 -0400 From: Kurt Lidl <lidl@pix.net> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note Message-ID: <51E0C3E7.7000503@pix.net> 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 7/12/13 7:02 PM, 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..) I don't think so. If you grovel through the NaCl stuff, you have to gen bit 32-bit x86, as well as x32 mad64 stuff, and they encourage ARM too. It's a shifting landscape, and they are now working on some intermediate PNaCl (portable), which smells like LLVM's IR code that they can convert to your native ISA at runtime. -Kurt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51E0C3E7.7000503>