Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] New function to convert floating-point types
Date: Mon, 29 Oct 2001 12:21:00 -0000	[thread overview]
Message-ID: <3BDDBA24.10803@cygnus.com> (raw)
In-Reply-To: <200110282344.f9SNifg21500@delius.kettenis.local>

> For a revision of the floating-point stuff in i386-tdep.c, I'd really
> like to have a function that converts between different floating-point
> types.
> 
> Here's my proposal.
> 
> Any objections to checking this in?

Not from me.

--

This prodded me to think about what DOUBLEST should be changed to.  Up 
until now I'd been thinking of some sort of generic floating point type. 
  However, looking at your case suggests instead something like:

	struct doublest
	  {
	    char value[a-large-number];
	    const struct floatformat *format;
	  };

Convert to DOUBLEST would just leave the format as-is.  Only when a 
conversion was really needed would it be converted.

nice,
Andrew

> Mark
> 
> 
> Index: ChangeLog
> from  Mark Kettenis  <kettenis@gnu.org>
> 
> * doublest.h (convert_typed_floating): New prototype.
> 	* doublest.c (convert_typed_floating): New function.
> 
> Index: doublest.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/doublest.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 doublest.c
> --- doublest.c 2001/10/28 22:06:27 1.5
> +++ doublest.c 2001/10/28 23:41:46
> @@ -713,11 +713,70 @@ store_typed_floating (void *addr, const 
>       TYPE_LENGTH (type) bits.  If the end of the buffer wasn't
>       initialized, GDB would write undefined data to the target.  An
>       errant program, refering to that undefined data, would then
> -     become non-deterministic.  */
> +     become non-deterministic.
> +
> +     See also the function convert_typed_floating below.  */
>    memset (addr, 0, TYPE_LENGTH (type));
>  
>    if (TYPE_FLOATFORMAT (type) == NULL)
>      return store_floating (addr, TYPE_LENGTH (type), val);
>  
>    floatformat_from_doublest (TYPE_FLOATFORMAT (type), &val, addr);
> +}
> +
> +/* Convert a floating-point number of type FROM_TYPE from a
> +   target-order byte-stream at FROM to a floating-point number of type
> +   TO_TYPE, and store it to a target-order byte-stream at TO.  */
> +
> +void
> +convert_typed_floating (const void *from, const struct type *from_type,
> +                        void *to, const struct type *to_type)
> +{
> +  const struct floatformat *from_fmt = TYPE_FLOATFORMAT (from_type);
> +  const struct floatformat *to_fmt = TYPE_FLOATFORMAT (to_type);
> +
> +  gdb_assert (TYPE_CODE (from_type) == TYPE_CODE_FLT);
> +  gdb_assert (TYPE_CODE (to_type) == TYPE_CODE_FLT);
> +
> +  /* If the floating-point format of FROM_TYPE or TO_TYPE isn't known,
> +     try to guess it from the type's length.  */
> +  if (from_fmt == NULL)
> +    from_fmt = floatformat_from_length (TYPE_LENGTH (from_type));
> +  if (to_fmt == NULL)
> +    to_fmt = floatformat_from_length (TYPE_LENGTH (to_type));
> +
> +  if (from_fmt == NULL || to_fmt == NULL)
> +    {
> +      /* If we don't know the floating-point format of FROM_TYPE or
> +         TO_TYPE, there's not much we can do.  We might make the
> +         assumption that if the length of FROM_TYPE and TO_TYPE match,
> +         their floating-point format would match too, but that
> +         assumption might be wrong on targets that support
> +         floating-point types that only differ in endianness for
> +         example.  So we warn instead, and zero out the target buffer.  */
> +      warning ("Can't convert floating-point number to desired type.");
> +      memset (to, 0, TYPE_LENGTH (to_type));
> +    }
> +  else if (from_fmt == to_fmt)
> +    {
> +      /* We're in business.  The floating-point format of FROM_TYPE
> +         and TO_TYPE match.  However, even though the floating-point
> +         format matches, the length of the type might still be
> +         different.  Make sure we don't overrun any buffers.  See
> +         comment in store_typed_floating for a discussion about
> +         zeroing out remaining bytes in the target buffer.  */
> +      memset (to, 0, TYPE_LENGTH (to_type));
> +      memcpy (to, from, min (TYPE_LENGTH (from_type), TYPE_LENGTH (to_type)));
> +    }
> +  else
> +    {
> +      /* The floating-point types don't match.  The best we can do
> +         (aport from simulating the target FPU) is converting to the
> +         widest floating-point type supported by the host, and then
> +         again to the desired type.  */
> +      DOUBLEST d;
> +
> +      floatformat_to_doublest (from_fmt, from, &d);
> +      floatformat_from_doublest (to_fmt, &d, to);
> +    }
>  }
> Index: doublest.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/doublest.h,v
> retrieving revision 1.6
> diff -u -p -r1.6 doublest.h
> --- doublest.h 2001/10/28 22:06:27 1.6
> +++ doublest.h 2001/10/28 23:41:46
> @@ -72,5 +72,8 @@ extern DOUBLEST extract_typed_floating (
>  					const struct type *type);
>  extern void store_typed_floating (void *addr, const struct type *type,
>  				  DOUBLEST val);
> +extern void convert_typed_floating (const void *from,
> +				    const struct type *from_type,
> +                                    void *to, const struct type *to_type);
>  
>  #endif
> 
> 
> 



  reply	other threads:[~2001-10-29 12:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-28 15:44 Mark Kettenis
2001-10-29 12:21 ` Andrew Cagney [this message]
2001-10-29 15:43   ` Mark Kettenis
2001-10-29 16:54     ` Andrew Cagney

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=3BDDBA24.10803@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@wins.uva.nl \
    /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