Double represented in IEEE 64-bit precision

Go To Last Post
64 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wonder if the AVRGCC compiler supports floating point with 64-bit precision?
Do the math.h also supports 64-bit precision (need to use asin(), sin(), acos(), cos())?
I need to calculate GPS position data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr gcc supports only 32 bits floats.
asin(), sin(), acos(), cos() are parts of libc and born as 32 bits there :)

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kalle (Anders Forsgren) wrote:
I wonder if the AVRGCC compiler supports floating point with 64-bit precision?
Do the math.h also supports 64-bit precision (need to use asin(), sin(), acos(), cos())?
I need to calculate GPS position data.
Ten Years After! (no, not the band)

Ok, so I'm wondering the same thing now. I'm using an Atmega1281 (ZigBit module) and need to calculate the distance between two GPS locations. I am using a spherical distance algorithm/equation which works perfectly well (precision of distance matches that of online calculators) when coded in C and run on a PC. The same algorithm/equation also works on the Atmega1281 (using AVR Studio 4) but the precision is lacking - distances off by a few tenths of a mile. I'm sure this is due to being limited to single precision math.
So, anyone know if it's possible to get code on an Atmega1281 to use double precision math? Using a new library or other type of compiler/linker?
Yes, I've searched an searched, so please no 'flames' about my not having searched first etc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did your prior search return also https://www.avrfreaks.net/index.p... (and the discussion linked to within)?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wmahoney wrote:
So, anyone know if it's possible to get code on an Atmega1281 to use double precision math?
Not from avr-gcc without changing the sources. And if, you will have to use newlib or some other non-avr-libc library.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JW (or, wek?),

I had not seen the thread that you pointed out. It looks very promising and I'm going to give it a go.

However, just after sending my post, I walked past a bookshelf here where I work and saw an IAR box with 'AVR' written across it. After making a few enquiries, I'm told "oh yeah, we have IAR for the AVR - didn't you know?".

Well, no - I didn't know! So, if all else fails, supposedly the IAR handles 64bit dbl precision math!

Thanks again!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What else is involved in making double eight bytes?
Edit the file that tells avr-gcc that double is four bytes and how to do arithmetic.
Write the functions used by those instructions,
including functions for conversion.
Write the math library.
Have I missed anything?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you missed anything?

Yes, the punchline to your stupid 'joke'.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Edit the file that tells avr-gcc that double is four bytes and how to do arithmetic.
It's two lines. You have to exchange a 32 by a 64 (DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE in avr.h)
Quote:
Write the functions used by those instructions,
including functions for conversion.
It's all there already.
Quote:
Write the math library.
It's all there already
Quote:
Have I missed anything?
Yes, chage 3 lines in t-avr to generate libgcc.

And then you have to generate the tools and libraries (configure and build) of course. It's all written how to do that.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
skeeve wrote:
Edit the file that tells avr-gcc that double is four bytes and how to do arithmetic.
It's two lines. YOu have to exchange a 32 by a 64 (DOUBLE_TYPE_SIZE and LONG_DOUBLE_TYPE_SIZE in avr.h)
Quote:
Write the functions used by those instructions,
including functions for conversion.
It's all there already.
Quote:
Write the math library.
It's all there already
Quote:
Have I missed anything?
Yes, chage 3 lines in t-avr to generate libgcc and then you have to generate the tools and libraries (configure and build). It's all written.
Now I'm really confused.
Someone who knows what he is doing just needs to change five lines and rebuild?
There are people on this forum who have put a lot more effort into avr-gcc than that.
Is it just that eight-byte doubles are so unimportant that no one who can has bothered?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm also confused. I looked at this a while back but gave up as I didn't understand enough but I thought that libm.a was going to need 64 bit versions of the add, sub, div, mod stuff? Are you saying there are generic (written in C) versions of these things in libgcc that will be used as a fall-back? If it's really this simple why has no one ever turned it on? It would be a MAJOR brownie point for the compiler given that only Imagecraft-Pro and IAR offer it already.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The confusion abounds...

such as, just where is this 'avr.h' file that only needs 2 lines edited, and what/where is 't-avr' that only needs 3 lines edited?

I have to agree with clawson:

Quote:
I'm also confused. I looked at this a while back but gave up as I didn't understand enough but I thought that libm.a was going to need 64 bit versions of the add, sub, div, mod stuff? Are you saying there are generic (written in C) versions of these things in libgcc that will be used as a fall-back? If it's really this simple why has no one ever turned it on? It would be a MAJOR brownie point for the compiler given that only Imagecraft-Pro and IAR offer it already.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

such as, just where is this 'avr.h' file that only needs 2 lines edited, and what/where is 't-avr' that only needs 3 lines edited?

Presumably in the source tree for either avr-gcc, libgcc?

EDIT: probably here in fact...

http://gcc.gnu.org/viewcvs/trunk...

See line 222

http://gcc.gnu.org/viewcvs/trunk...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Someone who knows what he is doing just needs to change five lines and rebuild?
Basically, yes.
skeeve wrote:
There are people on this forum who have put a lot more effort into avr-gcc than that.
Is it just that eight-byte doubles are so unimportant that no one who can has bothered?
The only thing 8-bit doubles were good for, IMO, is to make avr-gcc's C implementation compliant to the C standard that specifies some minimal requirements for double that are not satified by 32-bit double.

I can hardly imagine that anyone really wants to do 64-bit double arithmetic with an AVR, and even if, he will want to use hand-optimized assembler routines rather than code generated from vanilla C.

And as there are no 64-bit doubles in avr-gcc up to now, it's obviously not important enough. Such things are implemented by the one that deems it important enough to put work into it.

Doing it properly in GCC might be considerably less work than hacking around it in an application... Just like with floats or long long it's easy to hook in routines in an application, so you can write proper C code like "double ab = a*b;" instead of "long long ab = my_multiply_double (a, b);

Anyways, as soon as you have a routine you can grant it to GCC and integrate it there and get rid of performance issue forever. Hey it's free software that's written in a way so that you can extend it and make it better; but hardly anyone actually does it...

clawson wrote:
I looked at this a while back but gave up as I didn't understand enough but I thought that libm.a was going to need 64 bit versions of the add, sub, div, mod stuff?
No, libm is the wrong place. avr-libc implements some base arithmetic for float. But the reason it is in avr-libc is that some guys dropped it there and found it easier than integrating it in avr-gcc. Base arithmetic is part of the language, i.e. it should be implemented by the compiler: either directly in avr backend or as support function in libgcc.
clawson wrote:
Are you saying there are generic (written in C) versions of these things in libgcc that will be used as a fall-back?
Yes. There are even to versions you can pick from: The old fp-bit avr-gcc is using for SFmode (single float) and the newer soft-fp implementation.

For any thing that the backend deems as "too complicated" therer is code in libgcc to supply that support or parts in GCC to break code down to word_mode (you see this when adding two long long). A backend just has so supply base arithmetic for integer addition and moves and some other things, but DFmode (double float) support can be done without writing any line of code in he backend, similar applies to fixed mode support (_Fract, _Sat, _Accum).

As libc you will use newlib as avr-libc has no support for 64-bit double. newlib is even generic enough to handle -fshort-double.

clawson wrote:
If it's really this simple why has no one ever turned it on?
Because it's not only about turning it on: It will change the ABI. The current ABI implements double as float and therefore you can use avr-libc even with double: double will behave like float, sin will behave like sinf etc.

This would no more be true with double > float. Thus, you will want to have -fshout-double as multilib option: At current, avr-gcc behaves as if -fshort-double was always turned on (and DOUBLE_TYPE_SIZE depend on it), but with 64-bit doubles you need to doublicate multilibs: If cou compile code for a target in avr25, say, you want to link against

avr25/libgcc.a if -fshort-double is off
avr25/short-double/libgcc.a if -fshort-double is on

Now the question is: What should be the default for -fshort-double? On or off? Compliant to the C standard or compliant to legacy code and ABI?

Generating the multilins is not that hard, you need to add one dimension to the multilibs, i.e. extend the avr-specific genmultilib.awk. In versions prior to 4.7 it's even simpler, just extend MULTILIB_OPTIONS
and MULTILIB_DIRNAMES from t-avr (which now are auto-generated by genmultilib.awk).

Technical details:

Starting from the source three http://gcc.gnu.org/viewcvs/trunk/
You find in
./gcc/config/avr = the avr backend of GCC
./libgcc/config/avr = the avr part of libgcc

Makefile snippets are typically called t-purpose, i.e. t-avr are Makefile snip in libgcc and avr BE.

One level higher, you find t- snippets that might already fit most needs. For example, avr-backend emits ELF format and thus includes ./gcc/config/elfos.h so that it need not rewrite all of ELF stuff. avr-elf.h just performs some overrides.

To use such a t-file, integrate it in ./gcc/config.gcc or ./libgcc/config.host depending on if you work for avr-gcc or libgcc. Just search for "avr" and you find the places. You see that avr uses t-fpbit (located in ./libgcc/config)

To see how it works you find examples in other backends and in source comments, or maybe even in the internals documentation.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Additional complications:
Patches, e.g. those used by Bingo's script,
are needed to fix the compiler so that it works for AVRs.
Is this a political thing?
From recommendations on AVR-Freaks, without libm.a , even single precision arithmetic is bulky, slow and sometimes wrong.
I think that that is why Clawson was looking in the math library for arithmetic.

Regarding -fshort-doubles , would it have to have a default?
Could it be a required argument?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Quote:
Have I missed anything?

Yes, chage 3 lines in t-avr to generate libgcc.

Buy an AVR with more memory and wait longer for your results?

Is there any data on how big and slow the standard gcc software floating point libraries (that's what we're talking about, right?) would be on a 20MHz AVR?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Buy an AVR with more memory and wait longer for your results?

Is there any data on how big and slow the standard gcc software floating point libraries (that's what we're talking about, right?)

No.

It's about precision of double.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I understand that.
the 32bit floats used by avr-gcc currently are heavily optimized asm code from avr-libc or similar.
I htought that making the trivial change to the compiler build would cause it to use the generic gcc floating point code instead. Is there an 8-byte option for the avr-libc floating point?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Is there an 8-byte option for the avr-libc floating point?

No.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
clawson wrote:
Are you saying there are generic (written in C) versions of these things in libgcc that will be used as a fall-back?
Yes. There are even to versions you can pick from: The old fp-bit avr-gcc is using for SFmode (single float) and the newer soft-fp implementation.

For any real-world implementation, the generic double support would be absolutely unacceptable - a hand-optimized assembly version of the basic arithmetic operations would need to be supplied as well. That work has been done for 32-bit floats (but as you correctly noted, it is in the wrong place - libm.a shouldn't exist). But, to the best of my knowledge, the community has not adopted any generally accepted implementation for 64-bit floats yet.

This work MUST be done to obtain any acceptable level of performance; anything less than this would be just as bad as not having any support at all.

So, it is absolutely disingenuous to suggest that a trivial solution only requiring editing a few lines of code exists. Such a solution would not, in fact, actually be any solution at all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Luke,

Are you talking about poor performance then or do you think they'd actually be mathematically incorrect? Surely slow doubles is better than no doubles? (let's face it it's unlikely to be as bad as Imagecraft!)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm certain that I've occasionally seen mathematically incorrect results when using 32-bit floats, in situations where I've forgotten to link against libm.a but the compile succeeded anyway.

I'm afraid I cannot cite any specific examples off the top of my head, because it happened a couple of years ago.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm certain that I've occasionally seen mathematically incorrect results when using 32-bit floats, in situations where I've forgotten to link against libm.a but the compile succeeded anyway.

I think this is known in the libgcc trancendentals when they are compiled for AVR because they make assumptions about sizeof(int) that are then wrong. But I'm not sure that basic arithmetic operators (*/+-) are ever known to produce wrong results even when using libgcc code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI - I had tried the code listed here:

wek wrote:
Did your prior search return also https://www.avrfreaks.net/index.p... (and the discussion linked to within)?
JW

Sorry - the actual link is: http://www.mikrocontroller.net/t...

But I gave up on it as numbers kept turning into '0'. I then got IAR up and running only to find that 'everything I wrote was wrong' as far as IAR was concerned and nothing would compile. I'm not about to re-write code that's almost complete to suit IAR. I'm simply looking for a little more precision in calculating distances between two lat/long positions. I need to know if the satellite transmission hardware being controlled is close enough to a RAS (Radio Astronomy Site) location so that it needs to transmit on a different frequency.

I revisited the "avr_f64" code found at the quoted link above and got it to work. I found that what I needed to do was to convert values in a 'double' type into the 'float64_t' type using the functions provided in avr_f64. Then do the math (again using the provided avr_f64 functions) and then convert back to doubles (using ...). After handling the data this way, the calculations came out right on the money!

I'm using the file that has the trigonometric extensions provided by Florian Königstein. It does make your equation unreadable however, and counting parentheses was never so hard...

equation being used:
Distance = acos(cos(lat1)*cos(lng1)*cos(lat2)*cos(lng2) + cos(lat1)*sin(lng1)*cos(lat2)*sin(lng2) + sin(lat1)*sin(lat2)) * eRad;

equation altered for avr_f64 use:
Distance64 = f_mult(f_arccos(f_add(f_add(f_mult(f_mult(f_cos(lat1), f_cos(lng1)), f_mult(f_cos(lat2), f_cos(lng2))), f_mult(f_mult(f_cos(lat1), f_sin(lng1)), f_mult(f_cos(lat2), f_sin(lng2)))), f_mult(f_sin(lat1), f_sin(lat2)))), eRad);

Distance = f_ds(Distance64);

The lat# & lng# vars are float64_t types that got their values from doubles using the avr_f64 conversion functions as in:

//convert double's to float64's
lat1 = f_sd(latd1);
lng1 = f_sd(lngd1);

and don't forget to:
// Convert Lat/Long angles into radians
lat1 = f_mult(lat1, f_sd(Pi/180.0));
lng1 = f_mult(lng1, f_sd(Pi/180.0));

Also, with this code you simply uncomment what functions you want available in the avr_f64.h file and then only those functions are compiled & linked into your code.

Anyway, for what it's worth, this is what worked best for me! And, if Detlef_a (Nickname in the www.mikrocontroller.net forum) and/or Florian Königstein happen to view this - Thanks to you both!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lfmorrison wrote:
SprinterSB wrote:
clawson wrote:
Are you saying there are generic (written in C) versions of these things in libgcc that will be used as a fall-back?
Yes. There are even to versions you can pick from: The old fp-bit avr-gcc is using for SFmode (single float) and the newer soft-fp implementation.

For any real-world implementation, the generic double support would be absolutely unacceptable - a hand-optimized assembly version of the basic arithmetic operations would need to be supplied as well.
We need +, -, *, / and fmod for double arguments.
Are there existing hooks that would make any mixed mode special cases useful?
int*double, float*float->double?
These are things I think I could do.
Making the hooks would be another matter.
What about the math.h functions?
Would the default implementations be good enough?
What about the "%e" output format?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lfmorrison wrote:
This work MUST be done to obtain any acceptable level of performance; anything less than this would be just as bad as not having any support at all.
Your judgement is too myopic and just focused on some specific application.

64-bit double support is needed to render avr-gcc compliant to the C spec. This is a basic step for better support of avr-gcc as such, because a non-C-compiler will always be second choice.

Quote:
So, it is absolutely disingenuous to suggest that a trivial solution only requiring editing a few lines of code exists. Such a solution would not, in fact, actually be any solution at all.
People too often make the mistake that they only accept the absolute-perfect-fits-all-and-forever-futurama-makes-all-happy-award-winning-solution and *nothing* else.

Why not doing the first step first and contribute a framework that *works* and can be optimized later or even by user hooking in his code without the need of changing the tools?

In the current setup user *cannot* hook in hos code, except he writes clumsy code to explicitely call the stuff.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm all for the "making it work now, optimize later" approach.

Ideally, I'd like to see 64-bit double support added in, along with the fixed-point math support added in. It then gives the user a lot more choice as to how to write math intensive code.

And I'm all for giving the user more choice.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:
I'd like to see 64-bit double support added in, along with the fixed-point math support added in.
We should not build up dependencies where there are no dependencies. These features are completely unrelated from the GCC perspective. IMHO promote the impression that one thing is not usable/accepred/supported or whatever without the other just hinders things to get forward and people to get involved.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just had a look at the difference in execution speed for Rowley with 64bit doubles. Math functions are between 20 and 30 times slower than the 32bit versions.

I suppose that compliance with Ansi C is a useful ambition. It will come with costs though.

Most legacy AVR code is very cavalier with floats and doubles. Regular expressions will be cast up and down transparently by the compiler. Printf() formats will show up a few problems.

Most other 8-bit compilers do not bother with 64bit doubles. I can see few uses for them. The frequent candidate is NMEA strings, but there are more efficient ways of dealing with NMEA.

Personally, I would have thought that fixing the libgcc floating point features would be more important. Followed by getting register information into the debug ELF files.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, I guess you folks just write and write but don't read too well. Like I wrote, the "avr_f64" code located here: http://www.mikrocontroller.net/t...
works just great! No need for anyone to muck with AVR's-GCC.
And, for those who "can't see why anyone would need 64 bit precision"... Did you help design Java where they thought "Who needs unsigned integers?" What morons...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wmahoney wrote:
So, I guess you folks just write and write but don't read too well. Like I wrote, the "avr_f64" code located here: http://www.mikrocontroller.net/t... works just great!
The last posts deal with doing a proper double support in avr-gcc rather than how to work around that avr-gcc has no double support up to now.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
lfmorrison wrote:
This work MUST be done to obtain any acceptable level of performance; anything less than this would be just as bad as not having any support at all.
Your judgement is too myopic and just focused on some specific application.

64-bit double support is needed to render avr-gcc compliant to the C spec. This is a basic step for better support of avr-gcc as such, because a non-C-compiler will always be second choice.

In order to *really* satisfy the ANSI spec, all the major functions must be implemented as doubles. A compiler that fits the ANSI C spec, but which forces you to throw out any semblance of reasonable performance in the process, would automatically become a second- (or worse) choice in my books.

Obviously, any 64-bit double implementation (even hand-optimized) on a machine like the AVR will always offer worse performance than a correspondingly well-engineered 32-bit double implementation. So conforming to the ANSI spec will necessarily end up incurring a performance penalty. As such, we need to fundamentally question whether full ANSI compliance is really a worthwhile goal.

If we offer 64-bit doubles as an optional feature, disabled by default, which users can turn on if the need arises, I guess that would be an acceptable compromise. But full ANSI conformance, in the vast majority of use cases for a platform like the AVR, would actually be a hindrance rather than a help.

Quote:
People too often make the mistake that they only accept the absolute-perfect-fits-all-and-forever-futurama-makes-all-happy-award-winning-solution and *nothing* else.

Why not doing the first step first and contribute a framework that *works* and can be optimized later or even by user hooking in his code without the need of changing the tools?

In the current setup user *cannot* hook in hos code, except he writes clumsy code to explicitely call the stuff.


I don't propose that it must be perfect right away. At least, we can all agree that in the interim, any changes must do no harm to the rest of the users who don't need or want the baggage that comes with 64-bit doubles?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
wmahoney wrote:
So, I guess you folks just write and write but don't read too well. Like I wrote, the "avr_f64" code located here: http://www.mikrocontroller.net/t... works just great!
The last posts deal with doing a proper double support in avr-gcc rather than how to work around that avr-gcc has no double support up to now.
In context, I took it to mean that the avr_f64 code could be put in libgcc for use by the compiler.
IIRC long long has it own performance issues.
There is the matter of the math library,
but once we have double arithmetic,
couldn't we use an existing library written of C?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
This work MUST be done to obtain any acceptable level of performance

I don't see how you can say that until after you've actually figured out what the performance IS!

Especially since the low end of "acceptable performance" seems to be quite low in some cases (consider BASIC52.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-gcc functions work very well and efficiently with libm.a

avr-gcc functions do not work with libgcc.a

Judging by the difference in execution times for the Rowley 64-bit and 32-bit , I would guess a similar ratio. Granted, the avr-gcc are faster than Rowley in the first place.

You are either going to have a 'double=float' non-compliant compiler switch.
Or you provide sinf(), cosf(), etc math functions, and upset a lot of legacy code.

Either way you will have whingeing.

Personally I would fix several other avr-gcc features as a priority before going down this route. e.g. a known broken libgcc.a

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I just had a look at the difference in execution speed for Rowley with 64bit doubles. Math functions are between 20 and 30 times slower than the 32bit versions.

Has anyone anywhere documented these differences in cycles? I would like to compare them to my Q15.16 and Q31.32 fixed point numbers implementations.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
You are either going to have a 'double=float' non-compliant compiler switch. Or you provide sinf(), cosf(), etc math functions, and upset a lot of legacy code.

Either way you will have whingeing.

The user will have the choice, e.g. he will have to -fshort-double or -fno-short-double depending on what the default for short-double will be. So it's up to him reading the documentation then.

Besides that it might be desirable for package maintainers to fix double size to a specific value so that the user has /no/ choice, e.g. if the libc in the distribution does not support double > float.

Quote:
Personally I would fix several other avr-gcc features as a priority before going down this route. e.g. a known broken libgcc.a
What's the GCC bug number describing broken libgcc?

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What's the GCC bug number describing broken libgcc?

I have absolutely no idea.

However basic floating point should work without libm.a
You should only need libm.a for the specific functions.

There is nothing wrong with basic f-p support being large or slow. It should be functional.

If you link with a third-party library, it is perfectly legal to pull in replacement f-p primitives.

AFIK, this is how and why libm.a works. i.e. it has good functions and provides its own internal compiler f-p primitives.

I apologise if I have misunderstood the current avr-gcc situation.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

However basic floating point should work without libm.a
You should only need libm.a for the specific functions.


It does doesn't it? The faults you get by using libgcc.a instead of libm.a occur with someone transcendentatls (sin, cos, tan maybe?). I presume the Taylor series or Cordic or whatever is used to implement them cannot adapt to sizeof(int)==2 ?

Do you have some example where basic fp operators (*/-+) actually misbehave without libm.a ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Quote:
What's the GCC bug number describing broken libgcc?
I have absolutely no idea.
As you claim it was broken: Would you give an example so we can reproduce the issue?

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A search goes back to 2002:

https://www.avrfreaks.net/index.p...

but maybe things have moved on hugely since then?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is about acos from avr-libc, not about libgcc.

http://lists.gnu.org/archive/htm...

These function have been rewritten from scratch, so no need to warm up problems from 10 years ago...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My apologies. Some math functions will link ok with libgcc.a.
They give correct results, albeit fairly SLOW.

Some functions will not link at all:
exp() for example will give you a relocation error.

I had always assumed that you would link non :

crt.o module1.o ... moduleN.o   libc.a libgcc.a

you would link functions:

crt.o module1.o ... moduleN.o   libm.a libc.a libgcc.a 

It appears that all the functions are already in libc.a so you would not need a specific -lm.

So I wondered how or why should libgcc.a upset things. It appears that Studio4, Studio5, Mfile all end up with this as a default.

crt.o module1.o ... moduleN.o   libgcc.a libc.a libgcc.a 

Unless you specifically add -lc or -lm you will get libgcc.a being linked ahead of libc.a

GCC will always link with libc.a unless specifically told not to. GCC will link with libgcc.a whether you like it or not. Surely libgcc.a should only be linked as the last library?

Even if you do want to force libgcc.a ahead of libc.a for some reason, it should not give you relocation errors. (__subsf3 and __addsf3)

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

These functions are correct in libgcc but their callers in avr-libc are not always correct, see http://savannah.nongnu.org/bugs/...

The caller usere RJMP/RCALL and in the case where the callee like __addsf3 or __subsf3 is out of scope you get the mentioned error. This is *no* problem of the callee.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any reason for avr-ld linking libgcc.a libc.a libgcc.a ?

Where is this behaviour controlled ?

If libc.a or libm.a are calling externals with RJMP/RCALL, then this is their fault. If they want a short range call then they should provide their own.

Either that or avr-ld should provide a trampoline.

Whichever way you look at it, it needs fixing.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Whichever way you look at it, it needs fixing.

http://savannah.nongnu.org/bugs/... is still "open". Perhaps priority should be bumped above "normal"?

(the number of threads about this seems to suggest that might be an idea!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The command lines of subcommands called by the compiler driver are controlled by specs, see

avr-gcc -dumpspecs

The specs language is defined and documented in gcc.c. avr-gcc defines some SPEC strings like LINK_SPEC, LIB_SPEC or LIBGCC_SPEC, see avr.h.

Also read Controlling the Compilation Driver, gcc.

clawson wrote:
http://savannah.nongnu.org/bugs/... is still "open". Perhaps priority should be bumped above "normal"?
The maintainers are aware of it and nagging won't help as nagging won't add contributors or help in any other way.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry. I do not want to be negative. Surely we can come to some sensible conclusions? e.g.
1. is there a good reason for libgcc.a libc.a libgcc.a ?
2. should libm.a use JMP and CALL ?

This would tidy up the default crippling of libc.a
And you can always specifically use -lgcc if you want.

It would also enable extensions via external library in the traditional way.

Ah-ha. It appears that "— Macro: LIBGCC_SPEC" forces libgcc.a twice. Since it is cast in stone, it would be nice to know why.

And of course it should be quite possible to put 'good' objects into libgcc.a in the first place.

I am well aware that I can configure anything I like for my personal use. However it would be wise to resolve these anomalies for the official distribution.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, avr-libc should use JMP/CALL for "external" calls, i.e. calls outside a module. Read also the FIXME comment at top of lib1funcs.S.

The reason why code that belongs into libgcc is actually in avr-libc has historical reasons.

All this has beed discussed several times before in the mailing lists. The reason why the code is not in libgcc is because the authors did not contribute the code to GCC — for whatever reasons.

There was also some discussion in PR28718.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
because the authors did not contribute the code to GCC

Some sort of philosophical disagreement about licenses? One assumes that strong feelings must be involved to call the site "nongnu.org", and it's harder to imagine SW closer to the core of GPL-ness than gcc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My conclusion is fairly straightforward.

1. The libc.a functions should ALWAYS use jmp/call to external functions. All the functions are already in libc.a so there is no need for -lm

2. A separately compiled libm.a could provide its own internal functions that it accesses with rjmp/rcall

An average punter can have slow but functional f-p as a default i.e. no -lm
The anal retentive punter can add -lm to the command. In consequence she has functional f-p that even shaves a few bytes by using rcall.

Surely this would satisfy the philosophical feelings of developers? And be good for punters.

My personal preference is that externals should ALWAYS be jmp/call. If a linker chooses to optimise to rjmp/rcall that is the linker's perogative.

David.

Pages