avr-gcc-list
[Top][All Lists]
Advanced

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

Re: Why are switch statement tables in section .rodata which gets copied


From: Georg-Johann Lay
Subject: Re: Why are switch statement tables in section .rodata which gets copied to RAM with avr-gcc?
Date: Thu, 2 Apr 2020 11:06:14 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

Am 31.03.20 um 15:50 schrieb Peter Sommerlad (C++):
Hi,

as a newbie to AVR programming, I am porting Arduino Core code to modern C++17. I wanted to get rid of ugly large lookup tables that in PROGMEM that require separate assembly macro magic to access by normal C++ code.

My naïve assumption was that the compiler-generated tables for switch statement would end up in flash memory, because they are immutable.

A respective patch was effectively rejected, cf.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857#c17

and the links to the gcc-patches mailing list.  The patch was a no-op
for other targets but required 5 lines of code in the middle-end so
the avr back-end could hook in.  The maintainers didn't understand that
it could not be solved by putting the stuff in an other section and that
it is not possible to unroll generic accesses in the aftermath.

It turns out, that avr-gcc or the linker for the Arduino processor that I have access to, generate code to copy .rodata to .data in RAM. This is bad, and may have been the reason for these PROGMEM tables.

For some of the smaller processors the smaller switch statements would not end up using the table lookup, but especially the ATmega2560 has dense large number of cases.

You can switch it off altogether like with -fno-tree-switch-conversion.

Johann

Any ideas to circumvent it with standard code?

I am using avr-gcc 9.3.0

Better use v8; it generates better code.


Regards
Peter.




reply via email to

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