Skip site navigation (1)Skip section navigation (2)
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>