From owner-freebsd-arch@FreeBSD.ORG Sun Apr 6 19:49:15 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61F8E2EE for ; Sun, 6 Apr 2014 19:49:15 +0000 (UTC) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 215A6345 for ; Sun, 6 Apr 2014 19:49:14 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so5207413iec.5 for ; Sun, 06 Apr 2014 12:49:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0x0kHuG8qZ2jU2rto7nWGRSijJq1TZIkgqd6rYwHbr8=; b=N07Ooa5DgtDwvpPIHFXhJbhKSaW2kW7sPFkCFBEcksazhHdDvzXjYxtuooCnrF04a+ 11j/W8L0LTgjyv6o0tgc18fIZZ7ustqJHQa7z9jsK3B9EWodspyM0QWV+2xvGoquOtTK XI/I+fquCDop0hmzlyAc0kGYN00PrqGHA3ba12dgDz8bnDgIuA6PV3img9RYzMfOIOOJ T/UmnaEgV/EfyQLd/mrlWwpUIuVe3EjvxU4dImGUzJZ2hjorZ4ldgZsbiEpgHlFWyJcs kMMb+t5nitSfVYQZoSgMZzEZTB7PLG90zWNKmdt+HwyyMVG5vORLxjeAXYfEiUC54eyP yNsg== X-Gm-Message-State: ALoCoQkGwGwta6PnPfpxdx7Ss9G397Tynl12ssFTsGbHwZf4f1smVoP1/OH/jgb6mZ4JaSGsB8WI X-Received: by 10.50.25.7 with SMTP id y7mr14866011igf.17.1396813272337; Sun, 06 Apr 2014 12:41:12 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id b6sm23952115igm.2.2014.04.06.12.41.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Apr 2014 12:41:11 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Compiler toolchain roadmap From: Warner Losh In-Reply-To: Date: Sun, 6 Apr 2014 13:41:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <61229525-FD28-4311-B0C8-E3D32DAA27A8@bsdimp.com> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> <2E0EC8CB-B3EE-4DB8-A33D-58FD2107F14D@FreeBSD.org> <6A02504F-5543-4F91-92F6-7B4FB9A34DC4@ixsystems.com> <152D73EE-DF9E-4757-B547-F1F22B12C824@FreeBSD.org> <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org> <6418BE83-BE78-473B-9311-C849507FA885@ixsystems.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1874) Cc: David Chisnall , Baptiste Daroussin , Jordan Hubbard , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 19:49:15 -0000 On Apr 6, 2014, at 1:06 PM, Adrian Chadd wrote: > They may want to bring up an operating system (eg android) on a new > CPU family without having to wait for the upstream compiler to have > support. So they'll jump through hoops to make sure they can use their > internal compiler fork and then merge stuff back into upstream LLVM > when things have shaken out. We have basic out-of-tree toolchain support today (though it is a bit = clang centric due to esoteric differences in things like -B). I=92ve = been working in the background to improve this support, as well as bring = FreeBSD gcc changes forward to newer gcc=92s (at least the ones that = make sense to me: all the !x86 mods, the format changes, the platform = support). This will be critical if we=92re going to support, say, cross = building sparc64 from a ports-based compiler from scratch (which we have = extremely limited/poor support for today due to bootstrapping issues). I know there=92s also a big desire on some fronts to go all in on gcc = 4.9 or some other gplv3 compiler where the ARM or MIPS or = is so much better than the ancient 4.2.1 we = have in the tree. So it isn=92t even just the experimental bleeding edge = R&D lab folks that need to do this. Plus we have a boatload of issues with just doing a buildworld and/or = buildkernel with, say, gcc49=85 And our build infrastructure needs to = grow better version support for gcc and clang (right now you get one = version, which makes for some rockiness if you are building current in = some scenarios on 9.2 where clang versions differ). That=92s much to be done, and not a lot of doing. I=92m likely = forgetting other areas we need to focus on as well... > I'm definitely not arguing "make everything work for old MIPS and ARM > platforms". I'm totally on board with the "C99 and then C11 should > just be required at this point." But part of the point of supporting > external compiler stuff isn't just to make MIPS, ARM and PPC stuff > work. It's to keep us honest. We as a project treat non-x86 as a > second class citizen and it shows in our build infrastructure (ie, > everything is native.) It's similar to the 32 vs 64 bit platform stuff > - it again made the codebase better, even if it was "ew, DEC alpha.=94 You can do arm and mips native builds, it is just that the machines that = you have available are significantly under resourced compared to x86 = servers. I mean, you aren=92t going to find any ARM or MIPS machines = that can do a build world in 12 minutes=85 > As an example here - I get the feeling that people care not about > 32-bit x86 and would like it to die. The lack of interest and use of > freebsd/i386 by developers sometimes shows - suddenly KVA isn't > infinite anymore and a lot more stuff assumes large amounts of > physical RAM. But besides the recent push by Intel for all of their > x86 32-bit embedded stuff (which is all Linux, by the way), those > decisions also impact the 32 bit ARM platforms. Those aren't going > away. There=92s two issues here. One is people assuming KVA is cheap and other = things like this. The second is bodies to help (a) educate and (b) = implement for the smaller platforms. Over the years we=92ve grown up a = fair amount of embedded platform support. Now the time is ripe to push = to the next level of support: where the server guys talk to the embedded = guys and vice versa on a more regular basis. I see this happening a bit = already, and would encourage more of it. Warner