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


>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
Jim> - Since there are a lot of configurations that use the register
Jim>   info in tm-i386.h unmodified (see the diagram), and not all of
Jim>   those platforms have maintainers participating in this
Jim>   discussion, we may only change tm-i386.h in
Jim>   backwards-compatible ways.

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

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.

Jim> - Since we're doing our own layout, we have the opportunity to
Jim>   set aside the weird packing used by the FSAVE instruction, and
Jim>   have the registers hold something more meaningful.  Thus, I've
Jim>   split out the instruction segment selector and the opcode bits,
Jim>   previously different bitfields of the $fcs register, into two
Jim>   separate registers.

I'm not exactly clear what register you are describing here.  There
are two 48 bit registers, the FPU Instruction Pointer and the FPU
Operand Pointer.  Each are represented by an offset (bits 0-31) and 
a segment selector (bits 32 - 47).  Are you suggesting that they be 
represented by two pseudo registers each (fcs and fcoff for the FIP
and fds and fdoff for the FOP)?

After the first reading of your proposal, I had reservations about
using synthetic registers instead of architectural ones.  I strongly
believe that presentation issues should not unduely affect implement-
ation.  But in this case, this is a natural enough split.  I would
object vehemently if, for example, the FPU control register or FPU
status register was split into separate registers.

Jim> - I've changed the names of some of the FP control registers, to
Jim>   better reflect their meanings.  I think the names are more
Jim>   consistent than the old names, but please speak up if you
Jim>   disagree.

Jim>   The instruction (code) segment and offset are $fcs and $fcoff.
Jim>   The data operand segment and offset are $fds and $fdoff.

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.

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.

        --jtc

-- 
J.T. Conklin
RedBack Networks

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