Re: Unifying the x86 FPU register sets

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Jim Blandy <jimb@cygnus.com>
   Date: 17 Oct 1999 14:37:51 -0500

   >    We could make the control registers (except $fdoff and $fcoff)
   >    sixteen-bit values.  But that makes more work for platforms that do
   >    use FSAVE's 32-bit format; I assume those are the majority.
   > 
   > Although initially I thought I needed to use different register sizes
   > to implement things for exactly that format, I now see that I don't
   > need that.  The reserved bits are exactly in the right place to treat
   > it as an array of 32-bit values.  Only the code segment and opcode
   > registers need to be treated in a different way, as you did on the
   > Linux side.

   Okay, sounds great then.

I have it working now on the Hurd too.  I'll send a patch as soon as
I see your changes getting checked in.

What remains to be written is the function that prints the output for
the "info float" command based on the GDB register file.  If you
haven't done this already, I'm willing to give it a shot.  I should be
able to produce something useful by next weekend.

   > A remaining issue is what we do with the reserved bits?  From looking
   > at your code, it seems that you allow the user to modify the reserved
   > bits (except for the reserved bit in the opcode word).  Is that a
   > sensible thing to do?

   I think we need to maintain a distinction between the GDB register
   file and the structure the OS uses to exchange FPU state with the
   debugger.  For GDB's register file, those are 16-bit registers,
   zero-extended to make a 32-bit value.  (That should be stated in the
   header file; I'll fix that.)  For the OS structure, it's up to the OS
   to specify what those fields mean, and it's up to the OS-specific code
   in GDB to do the right thing with the register file.  If some future
   OS decides to put new registers there, then we should map them off to
   new GDB registers.

For now, GDB the Hurd will happily display what's in the reserved bits
that follow the control, status and tag word and the operand segment
selector in the data structure used by FSAVE and FRSTOR, but won't let
you change them.  If anybody complains I'll fill the reserved bits
with zeroes before loading them into the register file.

   This distinction isn't just pedantic, either --- the new SSE FXSAVE /
   FXRSTOR instructions save state in a different format, incompatible
   with FSAVE and FRSTOR, so either the OS interfaces will be changing,
   or the old ones will be emulated by code which changes from day to
   day.

So Intel has come up with yet another set of special purpose
instructions that diddle with the floating point stuff?

   I'm curious to see what Linux decides to do with the P-III support.  I
   haven't looked at the Linux kernel patches yet to determine what new
   ptrace interface they propose.  (Maybe I should post to the Linux
   kernel mailing list.  Ooh boy.)

You can do it ... Just take a deep breath ... even I did that some
time ago.  It even resulted in two lines of MY code being added to the
kernel :-).

Mark