[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [RFC] [bug #9348] asin (acos) & atan problem (64K bou

From: E. Weddington
Subject: Re: [avr-libc-dev] [RFC] [bug #9348] asin (acos) & atan problem (64K boundary)
Date: Thu, 28 Oct 2004 14:24:13 -0600
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Theodore A. Roth wrote:


I just did a cursory look at this bug to see if there was a simple fix.

It seems to me that moving the tables into a .c file would allow us to
have gcc force the table in the lower 64K. For example, the table_asin
defined as such in asin.S:

table_asin: DCB 7
        DCB 0x75, 0xA5, 0x7A, 0x2C  ; P7
        DCB 0x77, 0x5A, 0x90, 0xC5  ; P6
        DCB 0x79, 0x8B, 0xFC, 0x66  ; P5
        DCB 0x79, 0x7D, 0x10, 0xF8  ; P4
        DCB 0x7A, 0xCD, 0x83, 0x92  ; P3
        DCB 0x7B, 0x36, 0x3A, 0x9E  ; P2
        DCB 0x7C, 0xDB, 0xBF, 0xCA  ; P1
        DCB 0x7F, 0x49, 0x0F, 0xDA  ; P0
        DCB 0x00                    ; 0.0

would be moved to table_asin.c like this

 #include <avr/pgmspace.h>
 #include <avr/stdint.h>

 uint8_t table_asin [] PROGMEM = {
     0x75, 0xA5, 0x7A, 0x2C,  /* P7 */
     0x77, 0x5A, 0x90, 0xC5,  /* P6 */
     0x79, 0x8B, 0xFC, 0x66,  /* P5 */
     0x79, 0x7D, 0x10, 0xF8,  /* P4 */
     0x7A, 0xCD, 0x83, 0x92,  /* P3 */
     0x7B, 0x36, 0x3A, 0x9E,  /* P2 */
     0x7C, 0xDB, 0xBF, 0xCA,  /* P1 */
     0x7F, 0x49, 0x0F, 0xDA,  /* P0 */
     0x00                     /* 0.0 */

Then asin.S would need to have this added:

 extern table_asin

Does anyone see any flaws in this solution? I haven't had a chance to
do an experimental implementation yet.

Grepping through the avr-libc tree shows the problem to be more
expansive. I think all of these files will potentially have the problem:


Comments? Suggestions? Improvements?

Just make sure the table identifier(s) start with an underscore (or two, or whatever the rule is supposed to be, Joerg?), that way we don't trample on the user's space.

Good idea to fix it.

Of course, *eventually* we'll have to figure out how to have perhaps near and far pointers to break the 16-bit limit. Some people have complained about this on the m128, and it will get worse when bigger devices come online. But that's a different issue altogether...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]