HPGCC related ... - Hewlett Packard

This is a discussion on HPGCC related ... - Hewlett Packard ; On Mar 19, 7:58 pm, Claudio Lapilli wrote: > Disregard this part. It doesn't clarify anything... %f = double. %lf = > long double in ANSI-C, as well as in HPGCC. > > Claudio For what it's worth, ANSI C99 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25

Thread: HPGCC related ...

  1. Re: HPGCC related ...

    On Mar 19, 7:58 pm, Claudio Lapilli wrote:

    > Disregard this part. It doesn't clarify anything... %f = double. %lf =
    > long double in ANSI-C, as well as in HPGCC.
    >
    > Claudio


    For what it's worth, ANSI C99 specifies for printf()

    %f = double
    %Lf = long double

    Technically, there is no %lf, but C99 states that the l(ell) has no
    effect on a following f conversion specifier, making %lf synonymous
    with %f.

    %lf = %f = double

    Some non-compliant compilers, such as Microsoft, do use %lf for long
    double.

    -wes

  2. Re: HPGCC related ...

    On Mar 19, 4:07*pm, Wes wrote:
    > On Mar 19, 7:58 pm, Claudio Lapilli wrote:
    >
    > > Disregard this part. It doesn't clarify anything... %f = double. %lf =
    > > long double in ANSI-C, as well as in HPGCC.

    >
    > > Claudio

    >
    > For what it's worth, ANSI C99 specifies for printf()
    >
    > %f *= double
    > %Lf = long double
    >
    > Technically, there is no %lf, but C99 states that the l(ell) has no
    > effect on a following f conversion specifier, making %lf synonymous
    > with %f.
    >
    > %lf = %f *= double
    >
    > Some non-compliant compilers, such as Microsoft, do use %lf for long
    > double.
    >
    > -wes


    Even MS abandoned the long double years ago (at least on the x86
    platform, don't know on others), and now long double is mapped to
    double, to add more confusion.

    So %f, %lf, %Lf, the type (long double) and the type (double) are all
    the same thing in the x86 platform and also in gcc for ARM, therefore
    HPGCC mapped all types to double, even for scanf() where %f should
    technically be a float.

    In my code, I like to use %lf for doubles, to make scanf anf printf
    identical in syntax, but that's just my personal preference (but I've
    been doing it for so many years that I convinced myself that was ANSI-
    C, :-).

    Claudio

  3. Re: HPGCC related ...

    On Mar 20, 3:04 am, Claudio Lapilli wrote:

    > Even MS abandoned the long double years ago (at least on the x86
    > platform, don't know on others), and now long double is mapped to
    > double, to add more confusion.


    I seem to recall that this happened when they moved to the 32-bit
    Windows compiler, probably with Windows-95. It seemed a shame not to
    take advantage of the 80-bit floating point hardware that was there
    for the using. At the time, I was doing a lot of fractal
    programming. Using 80-bit floats instead of 64-bit allowed a few more
    zooms before having to resort to slower software code.

    Your comment got me curious about which x86 compilers still support
    the 80-bit long doubles. Of the current compilers that I could get me
    hands on: gcc (and variants like Cygwin, MinGW), Intel, Digital Mars,
    and Turbo C++ (it's back) all support 80-bit long doubles in hardware;
    MS and Open Watcom do not.

    I gather that ARM gcc only goes up to 64-bit floats, so it makes sense
    for hpgcc to do the same.

    This brings to mind what may be a silly question, but please pardon my
    ignorance. I know there is a _lot_ of code in hpgcc that is specific
    to the 49g+/50g. But there is also a lot that is standard to any C
    compiler (math libraries, std i/o, etc.). How much of ARM gcc's
    standard library had to be rewritten for hpgcc? For instance, the
    scanf() function that we've been discussing. Was there already a
    glibc scanf() for ARM, or did this have to be written from scratch? I
    see from the source code that some of the fast IEEE math routines are
    present while others are not (such as hyperbolics, expm1, log1p).
    Would these have to be written from scratch, or do they exist in an
    ARM glibc? Can you just recompile glibc (with a few tweaks for the
    mixed endian floats), or am I oversimplifying the process?

    Thanks for any insights you can pass my way.
    -wes

  4. Re: HPGCC related ...

    On Mar 22, 4:51*pm, Wes wrote:
    <...>

    > Your comment got me curious about which x86 compilers still support
    > the 80-bit long doubles. *Of the current compilers that I could get me
    > hands on: gcc (and variants like Cygwin, MinGW), Intel, Digital Mars,
    > and Turbo C++ (it's back) all support 80-bit long doubles in hardware;
    > MS and Open Watcom do not.


    Since the math coprocessor (or FPU unit for Pentium and up) works
    internally in 80-bit, it really makes sense to use the full precision
    for user types as well. I don't know why they dropped it, but they
    did.

    >
    > I gather that ARM gcc only goes up to 64-bit floats, so it makes sense
    > for hpgcc to do the same.
    >
    > This brings to mind what may be a silly question, but please pardon my
    > ignorance. *I know there is a _lot_ of code in hpgcc that is specific
    > to the 49g+/50g. *But there is also a lot that is standard to any C
    > compiler (math libraries, std i/o, etc.). *How much of ARM gcc's
    > standard library had to be rewritten for hpgcc?


    How much? Everything. We didn't take anything from the standard
    libraries, except the floating point emulation routines.
    Problem is, that functions in the standard libraries that come with
    gcc are heavily interconnected. For example, the math functions throw
    exceptions, wich pulls the entire exception machinery from the
    libraries, taking a lot of space. Executables were really big doing it
    that way. We had to rewrite routines to avoid linking in those extra
    modules. If you need certain specific routines, you can still link
    against newlib and it will retrieve the needed modules, provided you
    link newlib *after* you link against hpgcc libraries. This way it will
    first take our routines, then only take what's really needed from
    newlib.
    To give you an example, when I was trying to get C++ running, there
    was no 'operator new' defined. Since it's just one routine, I decided
    to link against libsupc++ and use the standard... big mistake! It
    worked fine, except that "Hello world" ended up taking 34 kbytes of
    code! So I wrote my own operator new and delete, and now it's back to
    normal size (less than 1 kbyte).
    The particular example of scanf, if I'm not mistaken it uses streams,
    so it brings several other modules from newlib. It had to be 'stripped
    down' in order to make it fit in the calc.
    It is unfortunate that those generic libraries are designed for much
    bigger devices than our modest calculator, and they are not written as
    a set of independent routines, but thinking on the library as a whole.
    That's just not what we needed for HPGCC.

    Claudio

  5. Re: HPGCC related ...

    On Mar 24, 6:08 am, Claudio Lapilli wrote:

    > > How much of ARM gcc's standard library had to be rewritten for hpgcc?

    >
    > How much? Everything.


    Hang on a second while I bump you guys up a few pegs on my admiration
    scale. All the more impressive what the hpgcc team has accomplished.

    Thanks so much for your reply. It *really* cleared up some things for
    me.

    Thanks,
    -wes

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2