From owner-freebsd-sparc64@freebsd.org Tue Nov 10 04:22:34 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E355A2BA68 for ; Tue, 10 Nov 2015 04:22:34 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 840B113C4 for ; Tue, 10 Nov 2015 04:22:34 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8375EA2BA66; Tue, 10 Nov 2015 04:22:34 +0000 (UTC) Delivered-To: sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83015A2BA64 for ; Tue, 10 Nov 2015 04:22:34 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.foxkit.us [192.65.240.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.wilcox-tech.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5262613C2 for ; Tue, 10 Nov 2015 04:22:33 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: (qmail 22234 invoked from network); 10 Nov 2015 04:30:25 -0000 Received: from c-71-57-141-247.hsd1.fl.comcast.net (HELO ?10.2.1.57?) (AWilcox@Wilcox-Tech.com@71.57.141.247) by mail.foxkit.us with ESMTPA; 10 Nov 2015 04:30:25 -0000 Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Sean Bruno , Marius Strobl References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <563F8385.3090603@freebsd.org> Cc: freebsd-arch , sparc64@freebsd.org From: Anna Wilcox X-Enigmail-Draft-Status: N1110 Message-ID: <56417100.5050600@Wilcox-Tech.com> Date: Mon, 9 Nov 2015 22:22:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <563F8385.3090603@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 04:22:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/11/15 11:16, Sean Bruno wrote: > On 11/08/15 07:55, Marius Strobl wrote: > > Unlike x86, sun4u and sun4v CPUs are only designed to be backwards > > compatible as far as the userland is concerned, > > host-PCI{,e}-bridges aren't compatible etc. So the kernel side > > always needs work and it simply isn't a matter of "testing" newer > > CPUs and models to work. Thus, the hardware is needed for > > developing support, see also below. > > > I'm not sure at which point I'd speak of people "clamoring" for > > support of some hardware; f. e. there also isn't a request for the > > graphics of Haswell and later Intel CPUs to be supported on the > > mailing lists every other day but you'll certainly agree that many > > are waiting for it. Now there likely are fewer people looking > > forward for later sun4u and sun4v processors getting supported but > > there definitely are people asking for it, just have a look at the > > lists. > > Now is the time for those users/people to step up and "clamor" for it. > The example of Haswell graphics is a good point. There is an active > developer working on the support with instructions on how to use the > test branch in github. We don't have an equivalent project ongoing > for the Sparc64 target AFAIK. I welcome being proven wrong here. > > > I don't see why sparc64 would be "the obvious odd arch" in that > > regard. The real problem is switching an architecture for which > > clang might have gotten en par with GCC after clang was changed to > > require C++11 for bootstrap. Given that clang was only the default > > on arm and x86 at that point in time, we are now stuck without an > > in-tree upgrade path on all other architectures. Granted, that > > might be lesser a problem on mips as these machines typically don't > > have enough CPU and RAM that self-hosting would be interesting in > > the first place. That still puts sparc64 into the same boat as > > powerpc and powerpc64, though. > > It's "obvious" to me from reading mailing lists and IRC chatter. This > is a poor justification on my part as it requires participating in > these to see the "obviousness" of the argument. > > I am personally pursuing clang enabled MIPS builds. Others are moving > the MIPS target to enable support for gcc from ports. Powerpc > developers have been working on clang and the clang intree is built > and installed in the powerpc images. From my impression, there hasn't > been a similar push intree to do the same type of things for the > Sparc64 target. Am I wrong here? Just as a further note, I had experimented in January of this year with making a binary pkg mirror for sun4u using my (comparatively sad) Ultra 60 and a cross-build system. Installation was fairly straightforward but I was having issues bringing up Clang and was having many issues trying to build "modern" packages using GCC 4.2.1. See my blog for some insight: http://blog.foxkit.us/search/label/sparc Unfortunately, truth be told, I gave up after the Freenode IRC channel gave me a whole heap of abuse and name-calling for trying to ask for any support with the sparc64 port. I couldn't find the documentation I needed to keep going and nobody wanted to help. If there are others working on this and I am not alone after all, I will gladly pull the Ultra 60 back on to my desk and do what I can to help out. GCC 4.8 or 4.9 would be a huge, huge, huge improvement in particular. - --arw -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWQXD8AAoJEMspy1GSK50U/qIP/0v4ltN6jkC7q5ijz/4x68QC sG8uk6r2Od9w5z8DF2RPLyNIRchvGTpxLMFPtCNX3Skdpchf/dK7wp/BBPjjzYEw BdkjgXEZiJape6YWI8XtbM681YrHoe9nYUkIMuKBKIMiMuhCTuExByca/x43GR8a U0RWbdQgLCRi7SmH4gLgZUTNp0yPhWE5O2IAHNoL+JwMC0Jwd/OjS9Za972+ZvAv 9d4aDmhmwFzdZPPxZps9iVytya27k0FfrY+vc6KHVsn1GHIh9SOcULBmrB6I5XOT D5JXA1OTmPHMhdd7/aY+6HWZO1eOk1kcwIKbKVXJuqNyl0twScHCfuSdE214SfDk CeYCUmIZs7Sh0+tUzIfFQHceD/sRomrXwoMY/6OzMiVGkGq/1A1PdgQheg0E1nbc DMQGV60drqFmVFVrmAKqhE8R7RtfTj5SvwMxjeLTEyPGehyv1mIarSCrebxCj75p mcJWqUiqjGuSIlV+vuEaSc9zbPh+ivAXzJHS0/gqp+WTdmH5LLECzzanspanxdTK 5Xa6KaP7CzcX4O7/uoIuB/tuczQVZGonPbT6apMlUpCPazxGvIgT26g9dGH4VfJM ugvDcfDzme0u04Ts2nkw5D08U/tDZMQfL1C7+BEYxSI811NY83BDrZCIkdX9IzdD ITFrIGCVocsrIlvShE0N =3Dk0k3 -----END PGP SIGNATURE-----