ICCAVR V7 IEE754 Floating Point Library Question

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I need to perform simple floating point math in a device using ICCAVR V7 and have concerns about the quality of the Code.
All that is required is the conversion of ascii numerical representation to/from single precision floats and multiplocation.

I am trying to determine now if I need to add an FPU to my platform or if I need to buy a third-party float library.

Of course, there's always the possibility of using a fixed point imnteger math solution.

Does anyon have any experience with floating point in ICCAVR V7? or have used another library? or other generalthoughts?

Thanks Muchly!

DFR

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

I presume that ICCAVR comes with floating point. It will always be done in software. There is no Atmel 8087 co-processor.

So you can use floating point math as much or as little as you like. And for most applications it will work quite fast enough. However you can always choose to work in integer millimetres rather than floating point metres. Your choice.

I am sure that ICCAVR float libraries will be perfect.

You probably have to check a few boxes to use %f in printf(). Wait a few minutes and Bob will have got out of bed, and he will tell you.

David.

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

Thanks David. I have sent a query to ImageCraft about IEE754 compliance testing.
I'm not looking for something better than what can be expected from some of the truly major compiler manufacturers.

I am going down this path in response to an observation from a fellow team-mate about what he conidered less than expected float accuracy. I don't have a failing test case right now, so the need for a geeral query.

DFR

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

Bob G. and I have gone back-and-forth on FP speed among ImageCraft and CodeVision. I think several chimed in with GCC numbers as well.

You should be able to do just fine for a few simple operations without looking elsewhere. There should probably be an atof() in stdlib.h for the conversion.

Note that most AVR floating-point implementations do not have a true "double"; the keyword will be accepted but ends up as a single-precision "float".

Multiplication should be pretty quick and be an integral part of the compiler. [In fact, that is the only time I have used floats in any of may applications--a single FP multiply to convert from internal units (A/D counts or similar) to user units (voltage, pressure, etc.) for display. It ended up faster than rolling my own scaled-integer stuff.]

I'll see if I can search out some rough numbers from those threads...
https://www.avrfreaks.net/index.p...
indicates a few hundred cycles for a FP mult and a hundred or two for an add.

https://www.avrfreaks.net/index.p...
flame war ;) with links to

https://www.avrfreaks.net/index.p...
where Bob's run showed ~300 cycles for ImageCraft.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Jun 12, 2008 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A 32 bit IEE754 is a 32 bit IEE754 is a 32 bit IEE754. Or were you suggesting that ICC's implementation might be "buggy" compared to CV or IAR or GCC or Rowley or whoever? I'd have thought that all these compiler were so "stable" in the area of something as fundamental as this that any bugs would have been worked out long ago. (and they could always just "borrow" the GCC implementation if they didn't mind adhering to GPL comliance! ;) )

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

Thanks Lee. also thank you for flagging me on the doub;e issue. FYI I'm not so concerned with execution speed of FP as its accuracy.

DFR

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

Then you may need to look at using the $3,000 IAR as it's the only one (I believe) that currently offers true (64 bit) 'double's

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

clawson wrote:
A 32 bit IEE754 is a 32 bit IEE754 is a 32 bit IEE754. Or were you suggesting that ICC's implementation might be "buggy" compared to CV or IAR or GCC or Rowley or whoever? I'd have thought that all these compiler were so "stable" in the area of something as fundamental as this that any bugs would have been worked out long ago. /quote]

Thanks Clawson. yes, I was concerned that not all FP implementations were "equal", not that I have any real reason to suspect this - Just doing due dilligence concerning a team member's observation.

DFR

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

You know your own applications. 32-bit floats keep most people happy. I believe that ICCAVR now do 64-bit doubles.

All operations can get suspect with subtracting two nearly equals etc. Sometimes a little care with the algorithm can avoid these anomalies.

I would have thought that all the implementations are bug-free. Get your mate to provide an example. Then you can compare it to a PC compiler or a spreadsheet. Spreadsheets often work to a greater accuracy. (known as keeping accountants quiet)

David.

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

Quote:

Thanks Clawson. yes, I was concerned that not all FP implementations were "equal", not that I have any real reason to suspect this - Just doing due dilligence concerning a team member's observation.

I edited above to post some prior informal benchmarks. No they ain't equal as CV is better. ;) But by this point they are all reliable and in the same ballpark.

Follow the links above; Rowley has 64-bit doubles.

I don't think that will bother you, Dana, (single vs. double) unless you plan a lot of chained operations or the like.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
I don't think that will bother you, Dana, (single vs. double) unless you plan a lot of chained operations or the like.

Or your missile has to hit a specific atom on the moon :lol:

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

http://www.math.utah.edu/~beebe/...

or similar (ieee754 compliance testing) may help.

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

I think GPS calcs need doubles.... anything more than 6 or 7 digits.... I recall running the 'savage' benchmark that did an exp then took the ln and if the same number that went in came out, all those fp mults and adds in the polynomial evaluator had to be working pretty good. Ask your doubting buddy to write a c prog on the pc to test his algo and use doubles, then compile it on the avr and use singles and see if the answers are close enough. The problem is adding a little number to a big number. You need to shift the smaller fraction right until the exponents are the same... and you have about 24 bits of fraction, so if the one number is 2^23 bigger than the other number, you shift the smaller one 23 times trying to line up the exponents. You only have about 1 bit left in the fraction when you add. Thats a diff of about 8 million.... so you cant integrate a dx position by adding 1 cm to 8 million cm for example.

Imagecraft compiler user