Date: Sun, 09 Aug 2015 15:29:34 -0700 From: Jordan Hubbard <jordanhubbard@me.com> To: Peter Jeremy <peter@rulingia.com> Cc: Bill Sorenson <instructionset@gmail.com>, freebsd-hackers@freebsd.org, "K. Macy" <kmacy@freebsd.org>, Kevin Bowling <kevin.bowling@kev009.com> Subject: Re: Sparc64 support Message-ID: <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> In-Reply-To: <20150809215403.GC20238@server.rulingia.com> References: <CACcTwYmS1c5uoO-WiJQDwgqYAevX7WZ7ZrP297hnOu7cNET3CA@mail.gmail.com> <mq3sg1$bno$1@ger.gmane.org> <CACcTwYnU=E-6sV3yLh3yKUSPZOg7967XV5ToXoSVPuNfOjF7hQ@mail.gmail.com> <CAHM0Q_NEYWxpHCwEdytfY6i9%2BRO2BebezzmenfQ_1c4u7zGrgg@mail.gmail.com> <CACcTwY=DcUREt5nJWo_eJfrB=3sQXBaS6nc%2B07fpZhxARD0zTQ@mail.gmail.com> <20150809215403.GC20238@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Aug 9, 2015, at 2:54 PM, Peter Jeremy <peter@rulingia.com> wrote: >=20 > 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. >=20 > The costs include: > - Whilst sparc64 remains tied to gcc4.2.1, FreeBSD as a whole can't = take > advantage of newer C constructs. I can speak to that a bit=E2=80=A6 I went through a bit of a kerfuffle = with 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 future async, multicore-aware applications. That = was=E2=80=99t just a pipe dream, 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 application base than any = Unix-derived system to date has ever even contemplated, much less = 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 personal 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 = is any feature that requires clang) then perhaps that might be a good = time to start thinking about bringing some of the OS X technologies back = into the fold. Until then, FreeBSD will of necessity be occupying a = niche somewhere in-between the original FreeBSD, where we made a = deliberate choice to focus on Intel and only Intel, and NetBSD. - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E>