The use of the "const" qualifier - GCC - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2024, 02:43:07 pm
content: I have a weird issue withstatic const char fred = "abcd";It causes some code to compile incorrectly. I am suspecting a linkfile issue. This is despite the project already containing lots of "static const" items - butnotin a particular module which has its own linkfile section.The const means it start in flash and doesnotget copied to ram.Regarding the typically used section names, the above goes into "rodata". If the "const" was missing, it would go into "data". So rodata is the same category as text, except that rodata should never be executable code.In GCC before v10, BSS and COMMON were used for the same stuff (e.g. int x;) but that doesnt apply here.Is the above right?Are there any common gotchas with the use of "const"?

author: RoGeorge
author_rank: Super Contributor
timestamp: July 26, 2024, 02:55:32 pm
content: I remember const as a qualifier that will make the compiler to error if you try to reassign it. Other than that, const is just like any variable.I don't think const will guarantee to put the variable in flash and to not copy it in RAM. In fact I expect a const variable to be copied to RAM just like a normal variable, but I'm no C expert.

author: madires
author_rank: Super Contributor
timestamp: July 26, 2024, 03:15:34 pm
content: Yep, 'const' simply tells the compiler that the variables's value is constant and can't be changed. However, there can be additional options to specify where the value should be stored. For avr-gcc:Code:/* stored in FLASH */const char fred[] PROGMEM = "abcd";/* stored in EEPROM */const char fred2[] EEMEM = "abcd";

author: langwadt
author_rank: Super Contributor
timestamp: July 26, 2024, 04:34:03 pm
content: Avr needs to do more, because it need special instructions to access progmem

author: Siwastaja
author_rank: Super Contributor
timestamp: July 26, 2024, 04:53:53 pm
content: Quote from: RoGeorge on July 26, 2024, 02:55:32 pmYeah - to be clear, C itself says nothing about this, it's up to implementation. But it's clear from peter-h's description that the linker scripts he uses are similar to what most people use with Cortex-M microcontrollers - i.e.,constqualified objects being put by compiler to .rodata, which is then put by linker script into flash and not copied to RAM during startup, saving RAM with the expense of (usually) slightly slower access. But you are free to write your own linker scripts for a different behavior.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 26, 2024, 05:27:19 pm
content: Quote from: peter-h on July 26, 2024, 02:43:07 pmDo you mean static const char fred = "abcd";QuotePrint out the value of a pointer to fred and make sure it's in the right memory area, and not being unintentionally copied to RAM.

author: peter-h
author_rank: Super Contributor
timestamp: July 26, 2024, 06:17:47 pm
content: Sorry...static const char fred[] = "abcd";Thatcode is working fine but it seriously breaks unrelated stuff, and I strongly suspect it is buggering up init values where these arenonzero(zero ones should go into BSS which is zeroed by definition). Like this

author: golden_labels
author_rank: Super Contributor
timestamp: July 26, 2024, 09:48:31 pm
content: peter-h didn’t describe, what is the issue he experiences, so for now I’m skipping his question entirely.I’m also making an assumption this is C, though that was not stated either.Quote from: madires on July 26, 2024, 03:15:34 pmIt says it can’t be written in the context in which the compiler sees the variable asconst. It doesn’t mean it can’t change.However,staticconsteffectively tells the compiler that it has a complete view of the variable. Which is the case in here. Of course that doesn’t indicate, where the variable goes or if it’s allocated at all, as you have noted.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 27, 2024, 01:40:31 am
content: Quote from: golden_labels on July 26, 2024, 09:48:31 pmRelated to ongoing thread:https://www.eevblog.com/forum/programming/weird-strcat()-behaviour/

author: golden_labels
author_rank: Super Contributor
timestamp: July 27, 2024, 01:39:53 pm
content: … which, the last time I checked, lacked minimal code reproducing the issue or any point to start from. This is exactly, why I mentioned peter-h failing to describe the problem. This is not the first time he expects help, but gives us nothing to work with.Inflating the thread with random pieces of information about C, in hope that maybe OP fetches something useful from that, is not productive.

author: peter-h
author_rank: Super Contributor
timestamp: July 27, 2024, 04:46:55 pm
content: Thanks for that helpIf I could post a code snippet which you might have time to read, say 10-20 lines, then I would have solved the problem quicker than typing it up.In my case, changing a declaration to const changed RAM addresses for all subsequent variables, so while "const" itself should not do anything bad (and is obviously better for r/o stuff which for whatever reason you don't #define instead) it can expose a problem.In my case it seems to have been a dodgy linkfile syntax.But when I started this thread I was looking for any gotchas with "const" from the much more experienced people here. I don't go on forums just to waste time. And - unlike some 99% - if I solve something, I post that too!

author: coppice
author_rank: Super Contributor
timestamp: July 27, 2024, 05:16:38 pm
content: Quote from: peter-h on July 26, 2024, 02:43:07 pmNo it doesn't. The const qualifier just means the compiler won't assign to the value. It doesn't mean it will be in flash, and it doesn't mean it won't be copied into RAM as the program starts. Lots of things have no flash or other forms of ROM, but const still works. Lots of things run code slowly from flash, so some things are configured to copy from flash to RAM at startup, and are used from RAM from them on. Some things have partitioned memory which demands things get copied from a starting position to a working position at startup.Now, its pretty common with modern flash MCUs that a C compiler will do what you said, but its neither a requirement or universal.

author: peter-h
author_rank: Super Contributor
timestamp: August 01, 2024, 08:37:18 am
content: Just to conclude this thread for anyone seeing it in the future, this turned out to be a really obscure linkfile issue, with DATA, which tooks a week or two of work to narrow downhttps://www.eevblog.com/forum/programming/a-specific-q-on-gcc-linker-script-syntax/The use of "const" merely moved some stuff around.

author: DiTBho
author_rank: Super Contributor
timestamp: August 01, 2024, 11:07:31 am
content: Quote from: coppice on July 27, 2024, 05:16:38 pmyup, it is much more common to compile an image designed to run entirely in ram, so all the addresses of all the functions and variables belong to the ram range, however the final binary image is then inserted into flash.What happens at startup?In flash there is a "loader" that copies the entire image into ram, then jumps to crt0, which in turn initializes some parts, and then jumps to main.However, when ram is scarce ... someone thinks of leaving some parts, such as LUTs, or in any case "immutable" data structures in the "constant pool", in flash.Things get complicated, especially if the flash is not accessible to uint8_t but only to uint16_t or worse to uint32_t.When I can, I try to propose the simplest possible scenario.

author: peter-h
author_rank: Super Contributor
timestamp: August 01, 2024, 11:25:27 am
content: DiTBho posted that he's blacklisted me so he probably won't see thisQuoteOne of the chinese copies of the 32F407 does exactly that - there's a thread on it here. It thus runs a bit faster, but probably not much. My own tests on loop timings (delay loops done for special hardware timing, in asm to prevent optimisation) actually run slower in RAM on the 32F417 than in FLASH, presumably because the CPU cache makes so much of a speedup. I found this when writing a boot loader, which runs in RAM.

author: coppice
author_rank: Super Contributor
timestamp: August 01, 2024, 11:34:14 am
content: Quote from: peter-h on August 01, 2024, 11:25:27 amThat is normal cache dynamics. If the device is executing little loops while running from fast main memory you see no benefit over slow main memory. Make the working set exceed the size of the cache and suddenly you see a large difference.

author: DiTBho
author_rank: Super Contributor
timestamp: August 01, 2024, 11:46:45 am
content: Quote from: coppice on August 01, 2024, 11:34:14 amI do NOT read his posts, but if someone quotes them, I see that he is there behaving like a petulant child.Yes, he is on the ignore list, and he will remain there,until he learns to respect others, the time dedicated to him, and open source.edit:I changed the subject of the sentence, so it's even clearer, in case another quote should be missing, whom I'm referring to.

author: coppice
author_rank: Super Contributor
timestamp: August 01, 2024, 11:48:57 am
content: Quote from: DiTBho on August 01, 2024, 11:46:45 amIf you are going to insult people try to insult the right one, you dumb moron.

author: DiTBho
author_rank: Super Contributor
timestamp: August 01, 2024, 11:50:05 am
content: Quote from: coppice on August 01, 2024, 11:48:57 am"dumb moron" is an insult!I am not here to insult, so hey? respect!I am writing form the smartphone, the keyboard is not good, so I missed a quote!

author: Simon
author_rank: Unknown
timestamp: August 02, 2024, 06:34:02 am
content: Quote from: DiTBho on August 01, 2024, 11:50:05 amSo to be clear you made a mistake. Right, now can we all be friends again?