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

[E. Weddington]

Theodore A. Roth wrote:

> Hi,
>
> 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 = {
>      7,
>      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:
>
>  libm/fplib/atan.S
>  libm/fplib/exp.S
>  libm/fplib/fp_cosinus.S
>  libm/fplib/strtod.S
>  libm/fplib/log.S
>  libm/fplib/tan.S
>  libm/fplib/asin.S
>
> 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...

Eric