Date: Sun, 6 Apr 2014 13:41:10 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@FreeBSD.org> Cc: David Chisnall <theraven@freebsd.org>, Baptiste Daroussin <bapt@freebsd.org>, Jordan Hubbard <jkh@ixsystems.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Compiler toolchain roadmap Message-ID: <61229525-FD28-4311-B0C8-E3D32DAA27A8@bsdimp.com> In-Reply-To: <CAJ-VmonC6chUAJF8fnYfXMvHUcD5t9tsfCb7qhSYexsBvhU7Aw@mail.gmail.com> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <F2A33EA8-14F2-4D62-9021-9023A1751E48@FreeBSD.org> <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> <B06E1588-8828-485F-A407-3F19231F8EA5@ixsystems.com> <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org> <6418BE83-BE78-473B-9311-C849507FA885@ixsystems.com> <CAJ-Vmom-19LujsTQ%2Bv4XozE%2BiEH18LMEQitBLC-At=DmsgkB%2BQ@mail.gmail.com> <EB9CE8A8-E897-4DE1-A8BC-80C6CC23E612@ixsystems.com> <CAJ-VmonC6chUAJF8fnYfXMvHUcD5t9tsfCb7qhSYexsBvhU7Aw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 6, 2014, at 1:06 PM, Adrian Chadd <adrian@FreeBSD.org> 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 = <weird-architecture-next> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61229525-FD28-4311-B0C8-E3D32DAA27A8>