future of sparc64 (was: Making C++11 a hard requirement for FreeBSD)
peter at rulingia.com
Mon Oct 9 06:49:50 UTC 2017
On 2017-Oct-07 19:06:29 +0000, "K. Macy" <kmacy at freebsd.org> wrote:
>On Sat, Oct 7, 2017 at 10:41 Mark Linimon <linimon at lonesome.com> wrote:
>> On Thu, Oct 05, 2017 at 07:12:28PM -0500, A. Wilcox wrote:
>> > That doesn't change the fact that sparc64 still exists, and with Oracle
>> > laying off Solaris as well, FreeBSD becomes a "way out" for people
>> > heavily invested (DC full of sparc64 gear, or such).
>> I have thought for some time that we've been a "way out" for Solaris
>> sites wanting to keep ZFS and not deal with licensing issues, and have
>> worked to keep sparc64 alive. (AFAIK FreeBSD is the only open source
>> sparc64/zfs solution?)
AFAIK Illumos still supports sparc64 and is probably an easier
migration for Solaris sites so I don't think that argument holds.
Also, we run into the same situation we had with Alpha - a basically dead
architecture that only runs on old equipment. Unless there's a critical
mass of FreeBSD developers that are willing to keep it running, we're better
off killing it quickly, rather than letting it soak up developer effort.
>My recollection of sparc64 from sun4v work was that unsupported operations
>would trap in to the kernel which would in turn trap in to a user space
>handler for floating point emulation.
Yes. I did some poking at that some time ago. The userland package is
basically a complete single/double/quad precision IEEE FP implementation
(see /usr/src/lib/libc/sparc64/fpu). I have a test suite for it but it
hasn't been committed and I'd need to check if it's developed any bitrot.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 949 bytes
Desc: not available
More information about the freebsd-sparc64