Hello.
Representations of real numbers in real.c are a little complex to
understand right now for me. I am still trying to understand them and
figure them out using gdb and cscope. Though conventions are given in
comments in real.c, I will still be trying to figure it out. The
equation and its bitwise representation is not pretty elaborated in
any documentation I could find.

x = s * b^e * \sum_{k=1}^p f_k * b^{-k}

    where
        s = sign (+- 1)
        b = base or radix, here always 2
        e = exponent
        p = precision (the number of base-b digits in the significand)
        f_k = the digits of the significand.

In mean time, I've tried real_round function to work like roundeven. I
will try to submit a clean patch along with roundeven implemented
separately with changes like in builtins.def, adding cases, etc.

void
real_round (REAL_VALUE_TYPE *r, format_helper fmt,
        const REAL_VALUE_TYPE *x)
{
#if 0
  do_add (r, x, &dconsthalf, x->sign);
  do_fix_trunc (r, r);
  if (fmt)
    real_convert (r, fmt, r);
#endif
  fprintf (stderr, "\nhere\n");
  real_value z;
  do_fix_trunc (&z, x);
  HOST_WIDE_INT i = real_to_integer (&z);
  fprintf (stderr, "\n i = %ld\n", i);
  if (i % 2)
    do_add (r, &z, &dconstm1, 0);
  else
    *r = z;
}

Thanks.
-Tejas

On Sat, 26 Jan 2019 at 03:02, Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Sat, 26 Jan 2019, Tejas Joshi wrote:
>
> > function with byte-byte comparison which also include mpfr. (Correct
> > me if I am wrong.) What is the significance of mpfr related to these
> > internal representations?
>
> real.c provides a fixed-size representation of floating-point numbers that
> allows for various non-IEEE formats supported by GCC, and also allows
> functions from dfp.c to be used for decimal floating-point formats.
>
> MPFR is used in GCC to provide operations that are nontrivial to
> implement, especially those that are nontrivial to implement in such a
> fixed-size context.  real.c operations wrap around MPFR ones where
> appropriate, doing whatever's needed in cases where there are non-IEEE
> semantics or sets of values.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Reply via email to