From owner-freebsd-sparc64@freebsd.org Mon Oct 9 08:26:04 2017 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C868E29244; Mon, 9 Oct 2017 08:26:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id C3B287FF73; Mon, 9 Oct 2017 08:26:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 4857A3C1D99; Mon, 9 Oct 2017 18:57:27 +1100 (AEDT) Date: Mon, 9 Oct 2017 18:57:26 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Jeremy cc: "K. Macy" , Mark Linimon , "A. Wilcox" , freebsd-sparc64@freebsd.org, freebsd-arch@freebsd.org Subject: Re: future of sparc64 (was: Making C++11 a hard requirement for FreeBSD) In-Reply-To: <20171009064931.GC93566@server.rulingia.com> Message-ID: <20171009175448.U1674@besplex.bde.org> References: <20171005234149.GE8557@spindle.one-eyed-alien.net> <59D6CA6C.1040502@Wilcox-Tech.com> <20171007174124.GA20810@lonesome.com> <20171009064931.GC93566@server.rulingia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=LI0WeNe9 c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=GRsoY76EHTS8MM7AKMcA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 08:26:04 -0000 On Mon, 9 Oct 2017, Peter Jeremy wrote: > On 2017-Oct-07 19:06:29 +0000, "K. Macy" 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