From owner-freebsd-amd64@freebsd.org Tue Aug 15 06:31:44 2017 Return-Path: Delivered-To: freebsd-amd64@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 0EF43DE5C38 for ; Tue, 15 Aug 2017 06:31:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id CDD562DDD for ; Tue, 15 Aug 2017 06:31:43 +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 mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 5AA9ED646BC; Tue, 15 Aug 2017 16:31:04 +1000 (AEST) Date: Tue, 15 Aug 2017 16:31:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Rang, Anton" cc: "freebsd-amd64@freebsd.org" Subject: Re: XSAVE vs. XSAVEOPT in fpusave / fpu_kern_enter? In-Reply-To: Message-ID: <20170815153457.F898@besplex.bde.org> References: 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=Yb7N30Zf c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=Axpjx6Mqo98pvSUj6-YA:9 a=MtvexjCta48XrdwP:21 a=3T3jv-qoMHGG4XTa:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 06:31:44 -0000 On Mon, 14 Aug 2017, Rang, Anton wrote: > While glancing at fpu_kern_enter, I noticed that fpusave() uses the XSAVE instruction, but not XSAVEOPT. The instance in cpu_switch.S is patched if XSAVEOPT is available, but should we also be able to use XSAVEOPT in fpusave as well? I can't see any reason why not, but I'm not 100% sure that the save area is set up properly in all cases. i386 does it in both places, but is differently badly organized. On amd64: In cpu_switch.S, xsave is inline and patched, by there is still branch logic to choose between fxsave and [xsave | xsaveopt]. The branch is not very slow and the xsave* case needs 3 extra instructions which would have to be patched out to avoid the branch by patching fxsave. In fpu.c, the save function is misnamed fpusave(). It actually saves the FPU state and various extensions starting with YMM. It uses branch logic to choose between fxsave and xsave but is missing support for xsaveopt. On i386: All saving goes through npxsave() which is not misnamed and not missing xsaveopt. However, this is misorganized and misnamed internally. It does the branch for xsaveopt directly, but calls fpusave() for other cases. fpusave() is misnamed by copy bad bits from amd64. fpusave() actually saves the FPU state and various extensions starting with MMX. It uses branch logic with 1 more branch than on amd64 to choose between fnsave and fxsave. NPX is the i486 name for the non-separate plain 80x87 FPU. Apparently Intel didn't want to scare programmers by mentioning floating point, or was preparing for non-FPU extensions starting with MMX. npx was a worse name than fpu at first since it was too special. Now it is a better name because it is less general after reinterpreting the 'n' (numeric) in it as "any sort of number, not restricted to floating point". Bitmaps and encrypted bits aren't numbers for most people, but they are close enough (closer than large cardinal numbers...). xpx or kspx (kitchen sink processing extension) would be a better name. and64 renamed npx to fpu at about the same time as the number extensions started exploding. The density of pure FPU support in amd64/fpu.c started lower than in i386/isa/npx.c and is now closer to 0. Intel started misnaming earlier. First, ssx was bowdlerised to sse. The x was rotated in the register names for xmm, then rotated alphabetically for ymm. avx has the x back in the right place. Bruce