From owner-freebsd-hackers@freebsd.org Sun Aug 9 23:26:29 2015 Return-Path: Delivered-To: freebsd-hackers@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 E113099D993 for ; Sun, 9 Aug 2015 23:26:29 +0000 (UTC) (envelope-from instructionset@gmail.com) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2D49782; Sun, 9 Aug 2015 23:26:29 +0000 (UTC) (envelope-from instructionset@gmail.com) Received: by oiev193 with SMTP id v193so49163873oie.3; Sun, 09 Aug 2015 16:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+3wF0QNNXgCFPYX8g/qkNAl7T3JXJ3bO6iPl+3EVu3k=; b=tVcTD23uH1FXf9i0RkjpkC68HgfcawGcdWXTtUMYtzmaZUc4SeTzzd2VmwYmWxM17o sw8riK2j8qQ6VBNc9GcIDriFSNpwyf5pGwh3coVHkoD4U8lH1spWJV3Ora7tjJCQQeBp pvowLsOkhGn9NOR6VBUaoHBRg0MLPYDs3tRu+lv55nMbx6KQOguhdedgxL99732t6RLB 3ZEXXql8LmwZfdI1ZBrQlxQWxccNZAq/GdZWwTsqT5sNMF9QE+sdpSFNfK1VhU3IRiW4 w8V0B8mVAQj5Z6/1mdteYYzzrWbRNAXHahT3lCVqrDAe4qitoCtdFtY99upaqzYfdqAN aECQ== MIME-Version: 1.0 X-Received: by 10.202.73.21 with SMTP id w21mr16214793oia.23.1439162788775; Sun, 09 Aug 2015 16:26:28 -0700 (PDT) Received: by 10.202.129.139 with HTTP; Sun, 9 Aug 2015 16:26:28 -0700 (PDT) Received: by 10.202.129.139 with HTTP; Sun, 9 Aug 2015 16:26:28 -0700 (PDT) In-Reply-To: <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> References: <20150809215403.GC20238@server.rulingia.com> <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> Date: Sun, 9 Aug 2015 18:26:28 -0500 Message-ID: Subject: Re: Sparc64 support From: Bill Sorenson To: Jordan Hubbard Cc: Kevin Bowling , Peter Jeremy , freebsd-hackers@freebsd.org, "K. Macy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 23:26:30 -0000 For what it's worth I'm not opposed to relegating tier 2 platforms to an external toolchain. I'm not building a product out of FreeBSD on sparc, and I already use GCC from ports where clang is unavailable. If it means killing GPL code in base and using libdispatch I think that is probably worth it. I am on the side of rolling in OS X technology into FreeBSD. It's one of the advantages the license brings. We get ZFS, dtrace, OS X stuff. Forgive my ignorance though but I am curious as to the benefit of having libdispatch in base vs being a ports dependency. Is there much in the base system where it would be used? And if libdispatch were a port dependency on by default, in tier 2 land where we must build ports ourselves anyway, we could build without it or live with that port being broken. -Bill Sorenson On Aug 9, 2015 5:29 PM, "Jordan Hubbard" wrote: > > > On Aug 9, 2015, at 2:54 PM, Peter Jeremy wrote: > > > > At this stage, it's not clear that SPARC has the critical mass of > interest > > needed to ensure its ongoing viability. Continuing to support an > > architecture incurs a non-zero cost to the Project as a whole so > continuing > > to suppport SPARC needs to demonstrate a benefit to justify that cost. > > > > The costs include: > > - Whilst sparc64 remains tied to gcc4.2.1, FreeBSD as a whole can't tak= e > > advantage of newer C constructs. > > I can speak to that a bit=E2=80=A6 I went through a bit of a kerfuffle w= ith the > project when I was agitating to get libdispatch incorporated into base so > that the project could have a decent multi-threading programming paradigm > (with none of the perils of pthreads) at its core on which to build futur= e > async, multicore-aware applications. That was=E2=80=99t just a pipe drea= m, either, > as I watched that exact evolution occur (and continue) in OS X and iOS. > It=E2=80=99s tried and tested and it Just Works across a wider applicatio= n base > than any Unix-derived system to date has ever even contemplated, much les= s > achieved. > > However, the need to support non-blocks aware compilers basically killed > the notion of pursuing that in the project. Yes, you can use libdispatch > without blocks, but it=E2=80=99s far less useful that way, and since my p= ersonal > needs are more than met by the amd64 architecture, one that by any metric > has become dominant in the industry, it was simply far more logical to > pursue that work in a fork (again!) and I stopped agitating for it. > > Now, should FreeBSD start insisting that clang support is mandatory to be > a tier 1 architecture and that tier 2 architectures should build with > external toolchains (on which they can also build with NO_FOO where FOO i= s > any feature that requires clang) then perhaps that might be a good time t= o > start thinking about bringing some of the OS X technologies back into the > fold. Until then, FreeBSD will of necessity be occupying a niche somewhe= re > in-between the original FreeBSD, where we made a deliberate choice to foc= us > on Intel and only Intel, and NetBSD. > > - Jordan > >