ATTiniy 167 / Float

[Erwan MARC-2]

Hello,

In our application, we have to make some mathematical operations and
first idea was to use directly float operations.
As a result, we can see that as soon as we use float data, there is a
block of 256 bytes used in RAM (_clz_tab) used (even if only a cast U32
=> F32 is made).
This is a very important amount of bytes for such a small component!

We know it is often better to work in "fix decimal" manner, even if for
code size it is worse, for RAM it is really better.
If we keep solution with float numbers, do you have a way to avoid such
amount of lost bytes in RAM?

Regards

EM


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Joerg Wunsch]

Erwan MARC <emarc@...> wrote:

> As a result, we can see that as soon as we use float data, there is
> a block of 256 bytes used in RAM (_clz_tab) used (even if only a
> cast U32 => F32 is made).

When using floats, do *always* link against -lm (libm.a).

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Erwan MARC-2]

we can't change target because of function not available on bigger chips
(LIN module on ATTiny 167)
the solution we can use at the moment if fix-decimal method, hacking
library or rewriting  it is not a good solution in my point of view: I
prefer using validated tools by developers or community than recoding
everything.
Regards
PS: resent to list, instead of direct talking.

Laughlin, Jeff a écrit :

> Hack up the C library and/or compiler? Or implement your own floating point library and avoid native float types and operators. Or switch to a beefier device.
>
> -----Original Message-----
> From: Erwan MARC
> Sent: Sunday, July 12, 2009 2:03 AM
> To: Laughlin, Jeff
> Subject: Re: [avr-gcc-list] ATTiniy 167 / Float
>
> yes it is.
> Is there any solution to reduce size of this area?
> we have been working on "fix decimal" solution and are close to to a
> solution but may have to switch again to float in the future.
> Regards
>
> PS for Jörg, I'll check if we have the option -lm or not, what is the
> impact?
>
> Laughlin, Jeff a écrit :
>  
>> It's probably scratch area for software floating point library, since
>> avr has no fpu.
>>
>>    

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Haci Helluri]

Hi,

I experienced a similar problem with attiny products. I think as soon as you use some function in math.h, the compiler copies a large portion (or maybe the whole) of the library into the RAM. I used register shifts and modulus algebra to avoid using those functions. Also,  the book titled Hacker's Delight helped me with some assembly tricks so I used some inline assembly where appropriate and forced the software inside the controller.

I would appreciate any further input on this though, seeing as how I'm no expert and would love to learn more tricks on doing math in limited memory space.

Norm

On Thu, Jul 9, 2009 at 9:41 AM, Erwan MARC <emarc@...> wrote:

Hello,

In our application, we have to make some mathematical operations and first idea was to use directly float operations.
As a result, we can see that as soon as we use float data, there is a block of 256 bytes used in RAM (_clz_tab) used (even if only a cast U32 => F32 is made).
This is a very important amount of bytes for such a small component!

We know it is often better to work in "fix decimal" manner, even if for code size it is worse, for RAM it is really better.
If we keep solution with float numbers, do you have a way to avoid such amount of lost bytes in RAM?

Regards

EM


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Joerg Wunsch]

Erwan MARC <emarc@...> wrote:

>> PS for Jörg, I'll check if we have the option -lm or not, what is
>> the impact?

libgcc.a contains helper functions for floating-point math which are
mostly auto-generated and thus not quite efficient.  libm.a, while
it's not its normal purpose, overrides a number of these functions
with more efficient versions.

It's been a historical mistake to separate libm.a from libc.a at all.
By the time avr-libc started, there was no reason other than ``because
it's always been that way'' to stuff the math functions into a
separate library.  (When Unix started on the PDP-11, there have
probably been resource exhaustion reasons for this separation, to keep
the linker's job doable at all.)

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list