Loading ...
Sorry, an error occurred while loading the content.
 

Re: [gnu-m68hc11] floating point libraries...

Expand Messages
  • Stephane Carrez
    Hi! ... You can override the floating point operations by providing them either explicitly (in .o files) or by providing them in a library that you pass to
    Message 1 of 7 , Oct 2 12:03 PM
      Hi!

      Alejandro Verdín a écrit :
      >
      > how can I override the standard floating point libraries (the elemental
      > ones: sum, substraction, div & mul) with my own ones.
      >
      > Best regards, Alejandro.
      >
      You can override the floating point operations by providing them either
      explicitly (in .o files) or by providing them in a library that you pass
      to gcc.

      You have to be cautious on the following:

      - use exactly the same name of symbols for the math operations as GCC
      (something like __addsf3, __subsf3, __mulsf3, __divsf3, __adddf3,
      __subdf3, __divdf3, ...)

      - use exactly the same prototype for these functions.

      - use the IEEE-754 format, or, also redefine all int <-> float conversions
      (something like __fixsfsi, __fixdfsi, ...)

      Take care that by default, we have

      sizeof (float) = sizeof(long) = 4
      sizeof (double) = sizeof(long long) = 8

      and in that case, you also need the __xxxdf3 functions.

      BUT, if you specify -fshort-double when compiling ALL your programs, GCC
      treats the double as a float and you don't need to implement the __xxxdf3.

      If the math functions you have implemented do not use exactly match
      the GCC functions, I suggest to write some wrappers that do the translation.
      Something like:

      float __addsf3(float a, float b)
      {
      float r;

      // translate a to your format
      // translate b
      my_op(a,b,&r);
      // translate r to IEEE-754
      return r;
      }

      If you have a better and smaller library to share with others, I think several
      people could be interested. The libgcc math implementation is pretty big.

      Stephane

      -----------------------------------------------------------------------
      Home Office
      E-mail: stcarrez@... Stephane.Carrez@...
      WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
      Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
      92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
      France
    • Mike McCarty
      ... [snip] I think that this is not enough. The compiler itself, running in the development environment, must generate bit patterns compatible with the
      Message 2 of 7 , Oct 2 12:13 PM
        On Mon, 2 Oct 2000, Stephane Carrez wrote:

        > Hi!
        >
        > Alejandro Verdín a écrit :
        > >
        > > how can I override the standard floating point libraries (the elemental
        > > ones: sum, substraction, div & mul) with my own ones.
        > >
        > > Best regards, Alejandro.
        > >
        > You can override the floating point operations by providing them either
        > explicitly (in .o files) or by providing them in a library that you pass
        > to gcc.
        >
        > You have to be cautious on the following:
        >
        > - use exactly the same name of symbols for the math operations as GCC
        > (something like __addsf3, __subsf3, __mulsf3, __divsf3, __adddf3,
        > __subdf3, __divdf3, ...)
        >
        > - use exactly the same prototype for these functions.
        >
        > - use the IEEE-754 format, or, also redefine all int <-> float conversions
        > (something like __fixsfsi, __fixdfsi, ...)

        [snip]

        I think that this is not enough. The compiler itself, running in the
        development environment, must generate bit patterns compatible with the
        execution environment. If you chose to depart from IEEE format, then
        the compiler must itself be rebuilt using the modified routines.
        Otherwise code like

        #define PI 3.14159265358979

        ...

        double Radians, Degrees;

        Radians = Degrees*(PI/180.0);

        won't work. The compiler will put IEEE bit patterns in for the
        denominator.

        So much more hacking away at the compiler is necessary.

        Mike
      • Stephane Carrez
        Hi! ... May be I miss-explained something. Constants generated by Gcc are IEEE-754. When they are passed to __xxxsf() everything is IEEE-754 and the result
        Message 3 of 7 , Oct 3 12:08 PM
          Hi!

          Mike McCarty a écrit :
          >
          >
          > I think that this is not enough. The compiler itself, running in the
          > development environment, must generate bit patterns compatible with the
          > execution environment. If you chose to depart from IEEE format, then
          > the compiler must itself be rebuilt using the modified routines.
          > Otherwise code like
          >
          > #define PI 3.14159265358979
          >
          > ...
          >
          > double Radians, Degrees;
          >
          > Radians = Degrees*(PI/180.0);
          >
          > won't work. The compiler will put IEEE bit patterns in for the
          > denominator.
          >

          May be I miss-explained something.

          Constants generated by Gcc are IEEE-754. When they are passed to __xxxsf()
          everything is IEEE-754 and the result follows the same format.

          The wrapper function translates input arguments to some internal/other
          format and translates back the result to IEEE-754. Everything that is seen
          by GCC code must be IEEE-754.

          To sum up, in your example everything is IEEE-754 (PI, Degrees, Radians,
          PI/180.0). There is no problem and it will work.

          > So much more hacking away at the compiler is necessary.
          >
          > Mike
          >


          Stephane

          -----------------------------------------------------------------------
          Home Office
          E-mail: stcarrez@... Stephane.Carrez@...
          WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
          Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
          92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
          France
        • Mike McCarty
          ... Could be. You said that in order to use non-IEEE format, all one had to do was write the link library routines to implement add, subtract, etc. ... Yes.
          Message 4 of 7 , Oct 3 3:09 PM
            On Tue, 3 Oct 2000, Stephane Carrez wrote:

            > Hi!
            >
            > Mike McCarty a écrit :
            > >
            > >
            > > I think that this is not enough. The compiler itself, running in the
            > > development environment, must generate bit patterns compatible with the
            > > execution environment. If you chose to depart from IEEE format, then
            > > the compiler must itself be rebuilt using the modified routines.
            > > Otherwise code like
            > >
            > > #define PI 3.14159265358979
            > >
            > > ...
            > >
            > > double Radians, Degrees;
            > >
            > > Radians = Degrees*(PI/180.0);
            > >
            > > won't work. The compiler will put IEEE bit patterns in for the
            > > denominator.
            > >
            >
            > May be I miss-explained something.

            Could be. You said that in order to use non-IEEE format, all one had to
            do was write the link library routines to implement add, subtract, etc.

            > Constants generated by Gcc are IEEE-754. When they are passed to __xxxsf()

            Yes.

            > everything is IEEE-754 and the result follows the same format.

            No, in the example you gave (you said it would be harder) you were
            discussing using a non-IEEE format *without* converter calls.

            > The wrapper function translates input arguments to some internal/other
            > format and translates back the result to IEEE-754. Everything that is seen
            > by GCC code must be IEEE-754.

            You gave three (IIRC) ways: use IEEE, use non-IEEE, but write wrappers
            to convert/reconvert, and use straight non-IEEE. In the last case (the
            context here) you said that one would have to write his own arithmetic
            package for run time. I pointed out that this is not sufficient, since
            the compiler will still do IEEE arithmetic itself, and not generate
            non-IEEE format constants.

            > To sum up, in your example everything is IEEE-754 (PI, Degrees, Radians,
            > PI/180.0). There is no problem and it will work.

            In my example, *nothing* was supposed to be IEEE, but the compiler would
            put IEEE numbers in polace.

            > > So much more hacking away at the compiler is necessary.
            > >
            > > Mike
            > >
            >
            >
            > Stephane
            >
            > -----------------------------------------------------------------------
            > Home Office
            > E-mail: stcarrez@... Stephane.Carrez@...
            > WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
            > Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
            > 92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
            > France
            >
            > To Post a message, send it to: gnu-m68hc11@...
            >
            > To Unsubscribe, send a blank message to: gnu-m68hc11-unsubscribe@...
            >
            >
          • Alejandro Verdín
            Hi! I developed a special format floating point libraries, three years ago. As I was using no more than 10 bit precision sensors end was urgently needing these
            Message 5 of 7 , Oct 12 7:50 PM
              Hi!

              I developed a special format floating point libraries, three years
              ago. As I was using no more than 10 bit precision sensors end was urgently
              needing these libraries, I crafted a 16 bit mantisa-8 bit exp floating
              point format ones. They are dirty, and not perfectly reliable, but they
              had been worked for me.

              Recently, I wrote wraps for __addsf3, __subsf3, __mulsf3,
              __divsf3, __fixsfsi, floatsisf and __XXsf2 comparation functions. They
              take 995 bytes en size. If somebody wants it, just e-mail.


              Best regards, Alejandro.
            • Toufiké HENNI-CHEBRA
              Hello, Is it possible for me to use your floating point librairies with GCC 2.95.2 ? I would like to use __fixsfsi, floatsisf and __XXsf2 comparation
              Message 6 of 7 , Nov 10, 2000
                Hello,

                Is it possible for me to use your floating point librairies with GCC 2.95.2 ?
                I would like to use __fixsfsi, floatsisf and __XXsf2 comparation functions.

                Thanks and best regards

                Toufiké HENNI-CHEBRA









                Alejandro Verdín a écrit :

                > Hi!
                >
                > I developed a special format floating point libraries, three years
                > ago. As I was using no more than 10 bit precision sensors end was urgently
                > needing these libraries, I crafted a 16 bit mantisa-8 bit exp floating
                > point format ones. They are dirty, and not perfectly reliable, but they
                > had been worked for me.
                >
                > Recently, I wrote wraps for __addsf3, __subsf3, __mulsf3,
                > __divsf3, __fixsfsi, floatsisf and __XXsf2 comparation functions. They
                > take 995 bytes en size. If somebody wants it, just e-mail.
                >
                > Best regards, Alejandro.
                >
                >
                >
                > To Post a message, send it to: gnu-m68hc11@...
                >
                > To Unsubscribe, send a blank message to: gnu-m68hc11-unsubscribe@...
              Your message has been successfully submitted and would be delivered to recipients shortly.