Sparc64 support

[Bill Sorenson]

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" <jordanhubbard at me.com> wrote:

>
> > On Aug 9, 2015, at 2:54 PM, Peter Jeremy <peter at rulingia.com> 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 take
> > advantage of newer C constructs.
>
> I can speak to that a bit…  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’t just a pipe dream, either,
> as I watched that exact evolution occur (and continue) in OS X and iOS.
> It’s 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’s 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
>
>