This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Unifying the x86 FPU register sets


   Date: Fri, 15 Oct 1999 12:16:25 -0500 (EST)
   From: Jim Blandy <jimb@cygnus.com>

   I'd like to restart the discussion we had over the summer about
   getting GDB's machine-level x86 FPU support in shape.

Great!

   - The idea here is to provide a common base for everyone to use.  If
     you see things that are inappropriate for your target, say so, and
     let's figure out the best way to handle it.

I can see no problems that would make it impossible to adapt the Hurd
to use these definitions.

   - If you see anything unclear or ambiguous, please say so.  Each
     register's meaning should be completely specified.  It should be
     completely obvious how each target should fill in the register file.
     It won't do us any good if everybody does it slightly differently.

What's the meaning of `SIZEOF_FPU_CTRL_REGS' supposed to be?  Does it
imply that GDB will expects its `pseudo' FP control registers to be a
32bit value each?  Or will we allow REGISTER_RAW_SIZE(n) for the
control registers to be different from 4 for FIRST_FPU_CTRL_REGNUM <=
n <= LAST_FPU_CTRL_REGNUM ?  And will we allow different values for
different targets?  This affects the floating point status printing
routine of course, but I think it should be possible to write it such
that it can deal with such differences.

I think my life would be easier if all of them except FCOFF_REGNUM and
FDOFF_REGNUM would be 2 bytes long.  That makes it possible to use the
`memcpy approach' with the FSAVE layout that Mach uses to store the FP
state.

   - I've got Linux working using this text, but it's still highly
     experimental.  Please read with a critical eye.

I'll start working on Hurd support if I don't hear about objections
from other people soon.  Could you make the Linux code available
somehow?

   - Since there are a lot of configurations that use the register info in
     tm-i386.h unmodified (see the diagram), and not all of those
     platforms have maintainers participating in this discussion, we may
     only change tm-i386.h in backwards-compatible ways.

Is this why you kept FPC_REGNUM?  It should be possible to replace
FPC_REGNUM with FCTRL_REGNUM in all targets without breaking any of
them, and remove FPC_REGNUM completely.

   - In particular, we may only add new register names onto the end; we
     may not insert new registers or rearrange existing ones.  This
     precludes having the FP register file match the layout used by the
     x86 FSAVE/FRSTOR instructions, in which the control registers
     precede the FP registers.  But this isn't such a tragedy, since the
     SSE FXSAVE / FXRSTOR instructions use a different format too, so
     what consensus might have existed before is somewhat broken already.

I think you're right.  I was one of the people who suggested using the
FSAVE layout, but I think the layout you chose is much more elegant.

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]