Unifying the x86 FPU register sets

Jim Blandy jimb@cygnus.com
Mon Oct 18 21:25:00 GMT 1999


> It's unfortunate that we cannot do this, as it requires the debug
> agent to have extra code to pack/unpack the floating point registers.
> This may not be an issue in a OS kernel, but it could be in embedded
> devices.  This was less of an issue pre-MMX, since FP operations are
> not typically used in embedded systems, but integer vector operations
> are more likely to be.

I think it really just means two copy loops instead of one; the stack
and control regions are just swapped.  Could you give this a try and
see how it goes?

I don't have strong opinions about the register names.  I've renamed
the FPU instruction and operand pointers almost as you suggest:

  FPU instruction pointer:  $fis, $fioff
  FPU operand pointer:      $fos, $fooff

Would $fiseg and $foseg be clearer?

> It took me a double, and even triple, take to figure out what $fcs,
> $fcoff, $fds, and $fdoff meant.  Since these registers are called the
> FPU instruction pointer and FPU operand pointer, why not $fis, $fioff,
> $fos, and $fooff?  I don't think anything has been gained by renaming
> them.

I mostly wanted to improve on the existing practice of stuffing the
opcode and the instruction pointer segment into the same GDB register,
which is lame.  As far as I know, all extant GDB targets which offer
any access to the FPU control registers at all do this.

> Jim> /* This register file is parameterized by two macros:
> Jim>    HAVE_I387_REGS --- register file should include i387 registers
> Jim>    HAVE_SSE_REGS --- register file should include SSE registers
> Jim>    If HAVE_SSE_REGS is #defined, then HAVE_I387_REGS must also be
> Jim>    #defined.
> 
> Don't you think we need to make this run-time selectable based on
> processor type?  For example, we have I/O cards with 386ex's with 
> no FPU at all and forwarding engine that uses a pentium MMX.  I'd
> like to support both with a single GDB.

Yes.  It's my understanding that we can accomplish this with the
gdbarch mechanism.


More information about the Gdb mailing list