future of sparc64 (was: Making C++11 a hard requirement for FreeBSD)

Bruce Evans brde at optusnet.com.au
Mon Oct 9 08:26:04 UTC 2017

On Mon, 9 Oct 2017, Peter Jeremy wrote:

> On 2017-Oct-07 19:06:29 +0000, "K. Macy" <kmacy at freebsd.org> wrote:
>> 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.

No, the trap method is almost never used by default, and should never be
used since it is so slow.

sparc64 on the 1 sparc64 system that used to be in the FreeBSD cluster
uses soft-float for long doubles by default (this is the gcc default)
since "hardware" (actually usuallly or always emulated by trap handlers)
for long doubles is so slow.  Something like 6000 times slower for
"hard" (trapping) long doubles on old sparc64 vs not so old x86 (with
x86 clock speed about 6 times higher, and better pipelining).
Soft-float for long doubles is only about 4000 times slower.  Real
hard-float for doubles and floats is only about 20 times slower (much
the same as for integers).

The only advantage of "hard" float on sparc64 is that it is easier to
debug, provided the bug is not in the trap handlers when it is harder
to debug.

Soft-float has more chance of working on sparc64 since it is needed in
some cases.  The flag for the case where it is needed is -msoft-quad-float.
On x86, clang is too broken to even refuse to support -msoft-float -- clang
silently ignores this flag, so this flag non longer works in kern.mk where
it is supposed to stop the compiler using an FPU in the kernel.  gcc-4.2.1
only has this bug on amd64.  The i387 happens not to be used anyway in code
without float variables.  SSE is more generally useful so the -mno-sse*
flags to prevent using it are more needed.


More information about the freebsd-sparc64 mailing list