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