From owner-freebsd-arch@FreeBSD.ORG Sat Jul 13 13:26:58 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E67D66FC for ; Sat, 13 Jul 2013 13:26:58 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by mx1.freebsd.org (Postfix) with ESMTP id C3179106F for ; Sat, 13 Jul 2013 13:26:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MPV00I00L5T3I00@smtpauth4.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sat, 13 Jul 2013 08:26:57 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.7.13.131821, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (unknown [76.210.63.131]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MPV00A67MOWPG10@smtpauth4.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sat, 13 Jul 2013 08:26:57 -0500 (CDT) Message-id: <51E155A0.6030409@freebsd.org> Date: Sat, 13 Jul 2013 08:26:56 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130711 Thunderbird/17.0.7 To: freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note References: <51E06B85.10109@pix.net> In-reply-to: X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 13:26:59 -0000 On 07/12/13 18:02, Adrian Chadd wrote: > On 12 July 2013 13:48, Kurt Lidl 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