Date: Mon, 9 Oct 2017 18:57:26 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Peter Jeremy <peter@rulingia.com> Cc: "K. Macy" <kmacy@freebsd.org>, Mark Linimon <linimon@lonesome.com>, "A. Wilcox" <AWilcox@wilcox-tech.com>, freebsd-sparc64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) Message-ID: <20171009175448.U1674@besplex.bde.org> In-Reply-To: <20171009064931.GC93566@server.rulingia.com> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <CAHM0Q_PuYhnaiQif0w_0gf_ip6QG0sCmMSFj=2xxq4RT42%2BEmg@mail.gmail.com> <20171009064931.GC93566@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Oct 2017, Peter Jeremy wrote: > On 2017-Oct-07 19:06:29 +0000, "K. Macy" <kmacy@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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171009175448.U1674>