From owner-freebsd-arch@FreeBSD.ORG Mon Jan 14 03:08:49 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 E5E31FA5; Mon, 14 Jan 2013 03:08:49 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs149.luxsci.com (rs149.luxsci.com [64.49.224.181]) by mx1.freebsd.org (Postfix) with ESMTP id B1924EE8; Mon, 14 Jan 2013 03:08:49 +0000 (UTC) Received: from rs149.luxsci.com (localhost.localdomain [127.0.0.1]) by rs149.luxsci.com (8.14.4/8.13.8) with ESMTP id r0E32nsO009386; Sun, 13 Jan 2013 22:02:49 -0500 Received: (from root@localhost) by rs149.luxsci.com (8.14.4/8.13.8/Submit) id r0E322Z6008938; Mon, 14 Jan 2013 03:02:02 GMT Received: (from sender 74627) (rs149.luxsci.com [127.0.0.1]) by LuxSci SP; Mon, 14 Jan 2013 03:02:02 +0000 Subject: Re: how long to keep support for gcc on x86? Content-Type: text/plain; charset=us-ascii From: "Isaac (.ike) Levy" In-Reply-To: Date: Sun, 13 Jan 2013 22:01:54 -0500 Content-Transfer-Encoding: quoted-printable References: <20130112233147.GK1410@funkthat.com> <20130113014242.GA61609@troutmask.apl.washington.edu> <20130113053725.GL1410@funkthat.com> <20130113202952.GO1410@funkthat.com> <20130113224800.GS1410@funkthat.com> <50F33B02.6040303@freebsd.org> To: Peter Wemm X-Lux-Comment: Message r0E31thR008892 sent by user #74627 Message-Id: <1358132522-7259997.45478983.fr0E31thR008892@rs149.luxsci.com> X-Comment: LuxSci SP Message ID - 1358132522-7259997.45478983 Cc: Adrian Chadd , Nathan Whitehorn , freebsd-arch@freebsd.org 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: Mon, 14 Jan 2013 03:08:50 -0000 On Jan 13, 2013, at 7:58 PM, Peter Wemm wrote: > On Sun, Jan 13, 2013 at 3:08 PM, Adrian Chadd = wrote: >> ... ? >>=20 >> As an embedded platform, I'd expect that people will want to support >> any feature which dramatically boosts performance whilst reducing = CPU. >>=20 >> Also, if Intel decide to keep trying to push low power x86 for mobile >> applications, rather than ARM, x86 may just make a resurgence in >> places you once thought were servers. >>=20 >> 32 bit x86 isn't legacy and won't be for a long time to come. >=20 > Our buildworld environment and embedded $everything isn't well known > for being embedded friendly. =20 IMHO, I believe the buildworld environment is quite friendly, but I = don't have anything except FreeBSD and OpenBSD to compare it to, > I'd wager that if somebody was trying to > use an i386 kernel in an embedded device where every last thing > counted, they'd be using an external toolchain targeted for their > platform and some very selective cross-building. =20 I'll take your wager- I'm one of those guys, lots of embedded FreeBSD on = tiny hardware- but I haven't been using any external toolchain or = compiler. Your wager may still be rational, your case is plausable, but since = 2004, I (and dozens of colleagues/friends/hackers) happily been = compiling FreeBSD, using zero add-on tools. (I've used a lot of Soekris = 4801 and 5501, and ALIX alix2d3 embedded boards). Typical Kernel and = world take approximately 18+ hours to build on a 4801, depending on the = kernel conf. Beyond Soekris and PcEngines, there is a glut of relevant industrial = single-board/embedded/funky hardware that is also 32 bit x86- some = pretty amazing gear, at varying levels of cost. The only port (external toolchain) I've installed on a build box was = dtach and sudo, (neither of which are obviously considered build = toolchain type utilities). I actually *enjoy* naked FreeBSD on these = platforms- no ports, no fluff, 500+ utilities in /bin and /usr/bin is = plenty of software to me :) FreeBSD kernel has had rock-solid support for these boards, http://wiki.soekris.info/Installing_FreeBSD Even the nanobsd build framework complements the soekris-specific = kernel/world build support nicely. > Compiler of > $your_choice would be on the table if you were doing external > compiling, and.. the default in-tree compiler does support AES-NI on > both i386 and amd64, and the logical other choice (gcc-4.6+ and > binutils) also does. External compiling is indeed possible, however, I've found it much = simpler for my purposes to simply build on the machine itself. (At the = end of the day, the apps I'm running have to *run* on the box, and if = they're too fat to compile there, my experience is that should set rough = expectations for how well the software will actually perform on the = platforms) > The only question is whether to go out of our way to support an > archaic, non-default compiler on one platform. I may be missing the point, I'm just a sysadmin who hacks in userland, = but 32 bit x86 doesn't seem to be disappearing any time soon. One more relevant use: Beyond the real possibility of more 32 bit x86 as = ARM competition, with the glut of 32 bit x86 'server' hardware I touch = in datacenters, much of it that crosses my hands will end up being "put = out to pasture" on the perimeter as FreeBSD network appliances, where it = can still shine rockin' PF/CARP/etc until the hardware completely dies. And relevant: the PfSense installed base: lots of 32 bit x86 hardware = (tons of SOHO routers on embedded boards, along with bigger kit in = datacenters). Best, .ike