Double Precision Floats for the Atmega128?

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

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?

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

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

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

Can you rewrite your code to use very long integers ?
That will speed up a lot in microcontrollers
:?:

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

pippo wrote:
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

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!

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

Hi,

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

:)

Regards,
Steve

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

SteveN wrote:
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 $$$$$$$$$$$$$$

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

Even though it's been 20 years since I last worked in assembler regularly, I still prefer to do everything in big integers instead of floating point :shock:

The largest known prime number: 282589933-1

Without adult supervision.

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

Steve_K wrote:

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?

Imagecraft compiler user

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

emilevanderlaan wrote:
Can you rewrite your code to use very long integers ?
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.

Imagecraft compiler user

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

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.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Adding floats is a long task. Multiplying floats is just a wee bit harder than multiplying longs 'cause you have to add the exponents, which you don't have in longs.

The largest known prime number: 282589933-1

Without adult supervision.

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

Torby wrote:
Adding floats is a long task. Multiplying floats is just a wee bit harder than multiplying longs 'cause you have to add the exponents, which you don't have in longs.

Correct, which is why I chose addition.

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

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

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.

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

glitch wrote:
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?

Imagecraft compiler user

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

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.

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

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...

Attachment(s): 

Imagecraft compiler user

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

Thanks for running the test and showing the results. You certainly piqued my interest, and began to wonder what the true difference would be.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

So I compiled this with imagecraft..... if we could get results from codewright, iar, gcc, metroworks and any other avr c compiler, then we'd at least know which one did fast floating point....

Imagecraft compiler user

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

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

Attachment(s): 

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

Very Interesting! I see they put a special case in checking for mult by zero.... I told Richard Man to do this in the ICC compilers a couple years ago, but Noooooo........
I ran this check on my PCs..... the 486 took just as long to mult by 0 and 1, but the pentium is faster.......

Imagecraft compiler user