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: Proposal for `info float' layout


   Date: Sun, 31 Oct 1999 03:25:57 -0500
   From: Eli Zaretskii <eliz@gnu.org>

   > Based on the input from the people on the list, I have made a proposal
   > for how the output of `info float' should look.  Please take a look at
   > it and don't hesitate to mail me your comments.

   I like this layout very much!  The following are some minor comments.

Thanks!

   > Status Word:         0x0000  IE DE ZE OE UE PE  ES  SF  C0 C1 C2 C3

   Perhaps it would be better to reverse the order of Ci bits: C3 C2 C1 C0.  
   This is how Intel docs print them, so it might be easier to interpret
   them in that way.

The docs I'm looking at aren't very consistent.  The text refers to C0
through C3, the status word diagram lists them in reverse order (since
C3 is the highest order bit, the interpretation table lists them in
the order C0, C3, C2, C1, and in the diagram that shows how the
condition codes are moved to the EFLAGS register they'r listed in the
order C0, C1, C2, C3 again.  I have no problem with changing the
order if someone has a real preference, but in absence of a convincing
argument I think the current order is the most logical one.

   > What's printed in the next column depends on the tag.  If
   > the register is `Valid', the floating point value is printed using the
   > "%g" specifier.

   I don't think we can be sure that "%g" will yield enough significant
   digits on all supported platforms.  I'd think "%.19Lg" is much
   better (LDBL_EPSILON is 1.08e-19 on my machine).  I expect people to
   want to see all the significant digits of the 80-bit format stored in
   the registers, and the defaults required by ANSI C aren't good enough.

I'm using "%+26.20Lg" right now.  That should be enough to print all
significant digits shouldn't it.

   > If the register is `Special', some additional
   > interpretation on the contents are done and for infinities and NaN's
   > one of the following is printed: `-Inf', `+Inf', `-SNaN', `+SNaN',
   > `-QNaN', `+QNaN'.  If the value is a denormal floating point number,
   > the value is printed and `Denormal' is printed in the last column.

   There is one more possibility: `Unnormal'.  These are the cases where
   the mantissa has some of its high bits zeroed, but the (biased)
   exponent is NOT zero.  This can happen if some random junk is
   interpreted as an FP number.  It is important to single out these
   cases because it almost invariably means a bug, while denormals can
   happen in correct code.

Indeed.  After I did some actual coding I realized that this part of
my proposal isn't really sufficient.  First, trusting the tag word to
accurately describe the contents of a register is dangerous, since in
gdb one can change the contents of a register without changing the
tag.  So the processing described above will have to take place for
all tags, not only `Special'.  Besides `Unnormal', there are several
other possibilities of what Intel calls `Unsupported Extended-Real
Encodings'.  Of these encodings only Pseudo-denormal is valid as an
operand, so I think it is a good idea to classify those.  The FPU
doesn't generate them, but user code could.  All other unsupported
encodings will simply display `Unsupported'.

   > It has also been suggested that the mnemonic associated with the
   > opcode should be printed.  While I think this is a good idea it is not
   > really easy to use libopcodes for this purpose.

   What are the difficulties with using libopcodes?

The only entry points are `print_insn_i386_att' and
`print_insn_i386_intel'.  These functions try to decode a full
instruction, which is bad since the FPU opcode register only contains
the opcode bytes, and no information about the operand.  Of course we
could disassemble the instruction pointed at by the FPU instruction
pointer, but I'd rather just print the mnemonic based on the contents
of the FPU opcode register.

Mark

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