Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: kevinb@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [rfc] Add some more floatformat types ....
Date: Fri, 17 Aug 2001 12:32:00 -0000	[thread overview]
Message-ID: <200108171931.f7HJVxB00450@delius.kettenis.local> (raw)
In-Reply-To: <3B7D4280.8010005@cygnus.com>

   Date: Fri, 17 Aug 2001 12:12:48 -0400
   From: Andrew Cagney <ac131313@cygnus.com>

   Ah, ok, now I understand.  So this means the original i386 did a 4:4:2 
   memory transfer when storing an extended float (long sigh)? The extra 2 
   bytes and the end of the `long double' always remaining undefined (long 
   double sigh)?  I've been hacking sane hardware for too long.

I think it shows here that the predecessor of the i386 was a 16-bit
processor.

   I think I'll clarify the `struct type . length' to:

   ``Length of storage for a value of this type. This is length of the type 
   and not the length of the value that resides within the type.  An 
   i386-ext floating-point value, for instance, only occupies 80 bits of 
   what is typically a 96 bit `long double'.''

Sounds good to me.  The key point here is that `struct type . length'
should match the debug info about the type.

   I'll drop the i387_ext from the list of things to add to floatformat.h.

I assume you mean that you'll leave it as it is now ;-).

   > I would simply introduce the builtin_type_i387_ext for the 80-bit
   > floating point type and keep builtin_type_long_double for the 96-bit
   > floating point type, both based on floatformat_i387_ext.
   > register_virtual_type would then indeed return builtin_type_i387_ext
   > for the floating-point registers.

   Ok.  The key thing here being that GDB gets two instead of one i387_ext 
   `struct type' (because the existing builtin_type_long_double can't 
   correctly describe an i387 register) which is really all I'm trying to 
   achieve.

Yep.

   --

    > The IA-64, for instance, has an 82 bit floating-point register.  That
    >    register is always represented in memory as 128 bits. 
   Consequently, my
    >    proposal includes ia64_ext128 and not ia64_ext82.
    >
    > So we only need a single floatformat_ia64_ext.  Why not keep the
    > floatformat_ia64_ext that we already have in ia64-tdep.c and move it
    > to ../libiberty/floatformat.c?

   Dam!  You spotted my cunning plan :-)  That is one of the next steps. 
   In the light of the exchange above, a double check on this one is in order.

Seems the ia64 stuff is even more braindamaged than the i386 stuff.

   Mark, this meaning that the ia64_ext should have a size of 128 and not 
   82 as it currently does in ia64-tdep.c?

I think so.  (But I also think we should rename it to ia64_reg as
Kevin proposes).

Mark


  parent reply	other threads:[~2001-08-17 12:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3B76164B.9060908@cygnus.com>
2001-08-16 11:36 ` Andrew Cagney
2001-08-16 16:55   ` Mark Kettenis
2001-08-16 20:10     ` Andrew Cagney
2001-08-17  6:08       ` Mark Kettenis
2001-08-17  9:13         ` Andrew Cagney
2001-08-17  9:40           ` Kevin Buettner
2001-08-17 10:12             ` Andrew Cagney
2001-08-17 11:12               ` Kevin Buettner
2001-08-17 12:19                 ` Mark Kettenis
2001-08-17 12:34                   ` Andrew Cagney
2001-08-17 12:51                     ` Kevin Buettner
2001-08-18 12:04                       ` Andrew Cagney
2001-08-17 12:30                 ` Andrew Cagney
2001-08-17 12:32           ` Mark Kettenis [this message]
2001-08-21  6:41 ` Fernando Nasser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200108171931.f7HJVxB00450@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox