XSAVE vs. XSAVEOPT in fpusave / fpu_kern_enter?

[Bruce Evans]

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