Hi,

I am using the Atmega128 with the CodeVision compiler. I need atleast 32 bit floating point precision and CodeVision only supports single precision. Does anyone know of a quick resource for such tools?

Author

Message

Hi,

I am using the Atmega128 with the CodeVision compiler. I need atleast 32 bit floating point precision and CodeVision only supports single precision. Does anyone know of a quick resource for such tools?

Hi Steve

I don'tt know Codevisione compiler, but 32 bit is single precision floating point, 64 bit is double precision floating point.

Have a nice day

Pippo

That will speed up a lot in microcontrollers

:?:

I don'tt know Codevisione compiler, but 32 bit is single precision floating point, 64 bit is double precision floating point.

Have a nice day

Pippo

Single precision floats use only 24 bits for the precision and the rest for the exponent I think. I found out that IAR has a compiler for the Atmega128 that supports the 64-bit doubles. I may have to switch compilers. Thanks for your support!

Level: Raving Lunatic

Joined: Wed. Nov 14, 2001

Posts: 3635 View posts

Location: Charlottesville, VA USA

Hi,

Sorry, can't resist....hope you are sitting down when you see the price :o

:)

Regards,

Steve

Hi,Sorry, can't resist....hope you are sitting down when you see the price :o

:)

Regards,

Steve

Do you know if the IAR tools will play well with Atmel's STK-500 board and AVR Studio? I guess I'll find out when I call IAR to get the $$$$$$$$$$$$$$

Level: 10k+ Postman

Joined: Tue. Nov 11, 2003

Posts: 10216 View posts

Location: Bartlesville Oklahoma USA

I am using the Atmega128 with the CodeVision compiler. I need atleast 32 bit floating point precision and CodeVision only supports single precision. Does anyone know of a quick resource for such tools?

Can you give an example equation you are trying to solve? I'm having a hard time trying to think of something that needs one part in 2 billion accuracy. Trying to add up the national debt in pennies?

That will speed up a lot in microcontrollers

:?:

I think this another old programmer's wives tale. You give me any equation that you think will execute faster with longs than floats, and I'll compile it and time a bunch of em in a loop and we'll see which one is faster.

I think this another old programmer's wives tale. You give me any equation that you think will execute faster with longs than floats, and I'll compile it and time a bunch of em in a loop and we'll see which one is faster.

You think you can do a 32bit floating point add in the same time you can do a 32bit integer add? This i've got to see. Also floting point libs tend to eat up much more code space than integer libs. The truth is, that if you can keep to integer math, the routine will run faster,a nd be more compact. Though depending on your application, you may lose precision.

Level: 10k+ Postman

Joined: Tue. Nov 11, 2003

Posts: 10216 View posts

Location: Bartlesville Oklahoma USA

Correct, which is why I chose addition.

Fixed point is another option, if you need limited precision.

I will present an equation for this floating point vs integer challage. My money is on the long (32 bit) integer math for the clear winner.

unsigned long a;

unsigned long b;

unsigned long result;

a = 4000000000; 4 billion

b = 1;

result = a+b;

--------------------------

float a;

float b;

result c;

a = 4000000000; 4 billion

b = 1;

result = a+b;

Now, here is why integer math will beat floating point. To add numbers with such a great difference in magnitude in floating point math, then one of them has to be "normalized". This means that you have to make the exponents the same before you can add the two numbers. You cannot add numbers with different exponents without this normalization process. This normalization requires shifting of the mantissa and addition or subtraction to the exponent. After this is done, the the mantissas can be added.

Believe it or not, floating point multiplication is the easiest. Multiply the mantissas, take care of overflow, then add the exponents, and take care of overflow.

If your CPU doesn't have a Floating Point Unit (FPU), then integer is faster for the same bit resolution.

bobgardner wrote:I think this another old programmer's wives tale. You give me any equation that you think will execute faster with longs than floats, and I'll compile it and time a bunch of em in a loop and we'll see which one is faster.You think you can do a 32bit floating point add in the same time you can do a 32bit integer add? This i've got to see. Also floting point libs tend to eat up much more code space than integer libs. The truth is, that if you can keep to integer math, the routine will run faster,a nd be more compact. Though depending on your application, you may lose precision.

Yes, but I issued a specific challenge: post ANY equation you think will eval faster at run time using longs rather than floats. If it uses cephes or other transcendentals, you need to go finf the long version of those, but I'll compile it and time it. How about y=m*x+b in longs and floats, over some range bigger than an int wil hold?

Even Y=MX + b will execute faster with integer math than floating point. Even if results "spill out" of shorts, or longs, multiple precision integer math can still be written that will beat the pants off floating point in terms of speed.

The reason for having floating point is to reduce storage space for a given dynanic range of numbers (not for speed).

The only change that a floating point operation has ANY chance of beating an integer operation is if the floating point numbers do not cause any overflow of the mantissas AND the exponents are the same, AND, the signs are the same.

For example: Add 1+1 in floating point.

If the floating point code is well written, then it can check for equal exponents and sign. Then all it has to do is add the 24 bit mantissa. However, these checks will almost certainly take longer to execute (even if well written)) than adding and storing the extra byte for the integer math (assuming 32 bit longs - apples to apples).

Write some test cases and check timing. If you can find ANY case where a floating point operation is faster than a 32 bit integer operation, I would like to see it.

You win. Long was 3x faster

fpbench July 29 2004 Bob Gardner

begin 1000 overhead loops

9222 tics 0.04 secs

begin 1000 fp adds

16483 tics 7261 net 0.032 secs 31733.2 flops

begin 1000 fp mults

16785 tics 7563 net 0.033 secs 30466 flops

begin 1000 fp mults by 1

18257 tics 9035 net 0.039 secs 25502.5 flops

begin 1000 fp mults by 0

15968 tics 6746 net 0.029 secs 34155.8 flops

begin 1000 fp divs

28539 tics 19317 net 0.084 secs 11928.1 flops

begin 1000 sin

243046 tics 233824 net 1.015 secs 985.4 sins/sec

begin 1000 log

198246 tics 189024 net 0.82 secs 1219 logs/sec

begin 1000 y=mx+b using longs

8099 tics 0.035 secs 28449.8 y=mx+b/sec

begin 1000 y=mx+b using floats

24269 tics 0.105 secs 9494.2 y=mx+b/sec

begin 1000 1k block moves

258736 tics 1.123 secs 890.5 K/sec

done. any char to repeat...

I ported your program to CodeVision, version 1.24.3a.

I removed all the timing and reporting, and used AVRStudio 3.56 simulator and stopwatch, setting up for Mega128 at 14.7456MHz. All times are in milliseconds.

Note the anomaly on the "long" y=mx*b. That is because the "overhead"

is NA in this case, since the "standard" overhead loop has two int-to-float conversions and a float assignment.

/* Ms. Net Ops/sec Overhead 36.69 0 --- FP Add 44.18 7.49 133511 FP Mult 61.78 25.09 39857 FP Mult1 60.74 24.05 41580 FP Mult0 39.81 3.12 320513 FP Div 70.49 33.8 29586 FP sin() 318.88 282.19 3544 FP log() 299.26 262.57 3809 LONG y=mx*b 11.94 -24.75 -40404 83752 FP y=mx+b 70.22 33.53 29824 BLOCK Move 559.42 522.73 1913 */

[edit] Also, to make a fair comparison the LONG y = m*x + b should really be done the way I do it in my apps, since slope is not likely to be an integer multiple: ly = rise * lx / run + b That results in one more 32-bit divide.

Lee

I ran this check on my PCs..... the 486 took just as long to mult by 0 and 1, but the pentium is faster.......