while loop in software

[c4757p]

The qualifier "constant" just means that the value doesn't change during runtime. It doesn't mean it's fixed during compile time.

Why it's not fixed value at compile time? What other values can it has?

42?

Code: [Select]

* (int*) &kSize = 42;

May or may not work, depending on platform, of course.

[hamdi.tn]

while (1)
  {
     keeptalkingaboutwhileloop();
  }
 

[0xdeadbeef]

Why it's not fixed value at compile time? What other values can it has?

I already answered the question, but I can do it again: a constant variable resides in a constant memory section. In an embedded projects, this is (Flash-)ROM. So you can exchange the ROM which contains these constants and get a different behavior without recompiling. This is how different calibration variants are handled in thousands of embedded projects in the last 15 years or so. If the compiler would treat a precompiler constant (define) exactly like a constant variable, this widespread concept would no work.
Besides, a global (non-static) variable with the qualifier const can't be simply removed as it's global.

[zapta]

I already answered the question, but I can do it again: a constant variable resides in a constant memory section. In an embedded projects, this is (Flash-)ROM. So you can exchange the ROM which contains these constants and get a different behavior without recompiling. This is how different calibration variants are handled in thousands of embedded projects in the last 15 years or so. If the compiler would treat a precompiler constant (define) exactly like a constant variable, this widespread concept would no work.
Besides, a global (non-static) variable with the qualifier const can't be simply removed as it's global.

I just tested it with the ARM gcc that comes with the LPCXpresso and the const it is optimized out beautifully as expected.

Case 1:

Code: [Select]

const int kkkk = 7;
volatile int jjjj = 0;

int main(void) {
  for (;;) {
    jjjj += kkkk;
  }
}

kkkk doesn't appear in the memory map and jjjj is incremented by the literal 7.


Case 2:

Code: [Select]

const volatile int kkkk = 7;
volatile int jjjj = 0;

int main(void) {
  for (;;) {
    jjjj += kkkk;
  }
}

kkkk appears in the memory map and jjjj is incremented by a value from memory.

The advantage of real consts over #defines is that they are part of the language, subject to scoping, namespaces, typing, etc. Same goes for inlined functions over #define based logic.

[0xdeadbeef]

Case 1:

Code: [Select]

const int kkkk = 7;
volatile int jjjj = 0;

int main(void) {
  for (;;) {
    jjjj += 2*kkkk;
  }
}
kkkk doesn't appear in the memory map and jjjj is incremented by the literal 7.

if so, this is a compiler bug, as it should be incremented by 14, shouldn't it?

The advantage of real consts over #defines is that they are part of the language, subject to scoping, namespaces, typing, etc. Same goes for inlined functions over #define based logic.

I wouldn't argue on this. Yet the behavior you observed is not the behavior I ever observed with any embedded commercial compiler (Keil, Diab, Windriver etc.) I ever worked with.
Guess there are setting for this, but the use of constants as calibration constant is so intensively used that I would have assumed that no embedded compiler would apply this kind of optimization by default.
Maybe a GCC thing since it was developed for desktop applications.
Besides: If a compiler removes a variable because it thinks it's futile, it should at least throw a warning.
In my experience, a global variable or function is never removed unless the whole module (*.o) is removed by the linker since not a single symbol within is referenced.

[zapta]

if so, this is a compiler bug, as it should be incremented by 14, shouldn't it?

Good catch. I posted the wrong version of Case 1 (now fixed).

Besides: If a compiler removes a variable because it thinks it's futile, it should at least throw a warning.
In my experience, a global variable or function is never removed unless the whole module (*.o) is removed by the linker since not a single symbol within is referenced.

It's semantically correct, not futile at all, but it doesn't mean that it is required in the mapping to an efficient machine code (such as loops that are inlined, variables that lives in regs or two variables that don't live at the same time and are assigned to the same memory location).

BTW, would be surprised if you your compiler/linker eliminates stuff in .o file granularity. You may end up with more linked library functions that you actually used.

Check jpelczar's post here (and ignore the salty language) https://www.eevblog.com/forum/microcontrollers/while-loop-in-software/msg575284/#msg575284

[0xdeadbeef]

It's semantically correct, not futile at all, but it doesn't mean that it is required in the mapping to an efficient machine code (such as loops that are inlined, variables that lives in regs or two variables that don't live at the same time and are assigned to the same memory location).

Yeah, but it's a global symbol that could be referenced by another C module. Hence a C compiler should never remove unused globals, only the linker should be able to do that since only at the linker stage, it's known if the symbol is referenced on a global scope.
Probably this is what happens here in a two stage process:
Firstly the compiler replaces the access to a constant variable with an immediate value inside the main module. Secondly, the linker detects that the variable is also not referenced externally, so it removes it completely.
This is a rather aggressive optimization strategy though. And surely not one that you can expect to exist in any project you'll ever work on.

BTW, would be surprised if you your compiler/linker eliminates stuff in .o file granularity. You may end up with more linked library functions that you actually used.

Well, it's even worse. In all the 32bit projects I worked on in the last years (mainly Freescale eSys and Infineon Tricore), the linker can even keep the whole module if nothing from it is referenced at all. This is said to happen because of debug references in the debug (Dwarf) part of the created (Elf) program. The only known workaround is to use the archiver to create a library (*.a) from the objects. Then a completely unreferenced module is usually removed.

Anyway, even if this works as you suspect in your project environment, there is no guarantee that it would in another project with a different compiler/target or mainly other compiler/linker (optimization) settings. For sure, it would not be optimized in the projects that I work on for a living, so if I had to review a piece of your code, this use of const variables be marked as finding ("avoid waste of ROM or runtime resources").

[zapta]

This is a rather aggressive optimization strategy though. And surely not one that you can expect to exist in any project you'll ever work on.

I am using gcc for a wide range of applications, from 8 bit MCUs to large distributed computation and server programs that run on thousands of cores and I always expect this level of optimization.

For sure, it would not be optimized in the projects that I work on for a living, so if I had to review a piece of your code, this use of const variables be marked as finding ("avoid waste of ROM or runtime resources").

In this case, every Arduino kiddie is using a better C/C++ compiler than you.  ;-)

BTW, by your example of configuration values, this expression should be computed at runtime. If your compiler really does it at runtime I would seriously look for a better compiler.

Code: [Select]

const int config1 = 100;
const int config2 = 5;
...
int i = config1 / config2;


[0xdeadbeef]

In this case, every Arduino kiddie is using a better C/C++ compiler than you.  ;-)

Even if you defined "better" as "using more aggressive optimization" that would be disputable to say the least.
BTW: "You" (as addressed in the quote) in this case is a multi-national company with thousands of SW developers.

BTW, by your example of configuration values, this expression should be computed at runtime. If your compiler really does it at runtime I would seriously look for a better compiler.

As I stated twice, not optimizing constant variables is the calibration concept used in the automobile industry since the beginning of microcontroller based control units (like for >20 years or so).
I would suspect though that it's also used in other branches.
Even if there would be GCC versions for the processors used, it would most probably never be shortlisted for a couple of reasons.

Even if you think that Arduino or freely available GCC derivates are the industry standard, just keep in mind that one day you might end in a project where your understanding of good style is not shared and code like yours will not pass a review.

[zapta]

0xdeadbeef, will the computer that you are using compute this divide operation at runtime?

Code: [Select]

const int config1 = 100;
const int config2 = 5;
...
int i = config1 / config2;


[0xdeadbeef]

0xdeadbeef, will the computer that you are using compute this divide operation at runtime?

Code: [Select]

const int config1 = 100;
const int config2 = 5;
...
int i = config1 / config2;


"Computer" is a strange term and I answered this already several times but again: the calibration concept used in all the microcontroller projects I know in the three companies I worked for (exact counting is difficult) in the last nearly 16 years forbids that the compiler removes this division. This division must be done during runtime else it would be impossible to have different calibration variants - which just differ in the flash section where these constants ares stored.
So it is not valid to assume that this is something that a good compiler must remove.

As a side note, maybe read through this:
http://en.wikipedia.org/wiki/Const_%28computer_programming%29#Consequences

In a nutshell: const doesn't mean that it's impossible to write to a const (if the memory section is physically writable, this is always possible though pointer magic).
The const qualifier is just meant to tell the compiler that the programmer doesn't intend to change the value. This allows for certain optimization like keeping the value inside a register.
Regarding variables, "const" is somewhat the opposite of "volatile" since volatile means that the compiler must never read/write a register instead of a variable.

[zapta]

This division must be done during runtime else it would be impossible to have different calibration variants - which just differ in the flash section where these constants ares stored.
So it is not valid to assume that this is something that a good compiler must remove.

That's what the 'volatile' keyword is for.

[0xdeadbeef]

That's what the 'volatile' keyword is for.

Not really. I already described what the volatile qualifier means for variables.
Anyway, if you look at properly written C code, you'll see that volatile on variables is not used to avoid them being removed but to force the compiler to always use the variable in memory instead of local copies.
This is needed if the variable is written/read in different interrupt/task levels to avoid incoherency. Also peripheral registers are volatile to avoid read to / writing to temporary copies.
Obviously, declaring a variable volatile also means that its memory location must not be removed, but that's not the main intention.

[miguelvp]

This thread is volatile as we don't know the state at any given point in time so we must not cache it and spend extra cycles fetching its contents that no longer have anything to do with while loops.

[0xdeadbeef]

Honestly, this thread was doomed from its very start

[westfw]

it would be impossible to have different calibration variants

I understand what you want, and I sure hope that whatever compiler you use (or the infrastructure you have added) has keyword phrases that enforce that behavior ("extern volatile const"?  "__pragma__(calibration)"?), because "calibration constant" are for sure well outside the language definition/specification, and compile-time evaluation of constant expressions is an important and common part of reasonable optimization.   (and oh, what a nightmare to debug, should the compile decide that it can optimize your constants away in addition, but not in multiplication...)

It is the sort of compiler behavior that I would be really reluctant to count on! 
(not all compilers put "const" variables in flash in the first place.  Especially on harvard architecture machines.)

For actual constants, "static const" should be better than just "const"...

[0xdeadbeef]

I understand what you want, and I sure hope that whatever compiler you use (or the infrastructure you have added) has keyword phrases that enforce that behavior ("extern volatile const"?  "__pragma__(calibration)"?), because "calibration constant" are for sure well outside the language definition/specification, and compile-time evaluation of constant expressions is an important and common part of reasonable optimization.   

I'm not aware of any specific trickery that had to be done to get it right and I think I already looked at all the places where it could have been applied.
Then again, in a large company, you have dedicated departments just for the compiler setup. So I wouldn't rule out that there is something I always overlooked.
Anyway, stuff like this is always discussed with the compiler vendor. It's not like trying and hoping the best if that's your concern. One of the reasons why a vanilla GCC is never on the short list.

(and oh, what a nightmare to debug, should the compile decide that it can optimize your constants away in addition, but not in multiplication...)

I was involved in all kind of unpleasant debugging stuff, but never saw a behavior like this.
BTW: if you think that's tricky then wait until you map your calibration ROM to RAM though MMU or SDA pointer trickery, write a new value to RAM and observe how the CPU takes some constants from RAM but some still from ROM due to cache lines not being flushed. That is hard to debug.

It is the sort of compiler behavior that I would be really reluctant to count on! 

Then I guess you shouldn't drive any car built after 1980

(not all compilers put "const" variables in flash in the first place.  Especially on harvard architecture machines.)

Well, assuming we're talking about microcontrollers, the constants are obviously always in flash. The only question is if they are then copied to RAM or accessed from Flash.
Harvard architecture doesn't really have much to do with this. It's just that the compiler needs to create different opcodes to read from ROM and RAM but a good compiler hides that from you.
E.g. at the beginning of the century/millenium, the 1st version of AVR-GCC was not able to fetch constants from flash due to other opcodes for reading from flash, so you either had to read from the RAM copy
or use specific intrinsic commands. At the same time, commercial compilers could already do this without workarounds.
Anyway, in the projects I worked on, this is just a matter of locator setup and maybe runtime initialization (which we usually do on our own anyway).

[Dinsdale]

Never use a while loop. While loops are current controlled. A for loop is voltage controlled. Use those.

[jpelczar]

...Shitty code with loops like while(i-->0); do make "delay" is reduced to nothing.

Not if if i is volatile, right?

Yes, but IMO it's better to put

Code: [Select]

while(i-->0) __asm__ __volatile__("");

This will produce MUCH better code as compiler will not generate unneeded loads/stores for i.

For multithreading/multiprocessing - instead of volatile on modern CPUs (like Cortex A15 MPCore, A12, BigLittle, etc.) I use either assembly code (ldrex/strex) or compiler's atomic operations (#include <atomic>) if memory operations require ordering, but the code really depends on the use case. Avoid volatile at all cost, except for memory mapped I/O. Sometimes I see programmers use volatile because they don't have knowledge to fix their shit, and their code works only because optimizer doesn't do something with the code.

[miguelvp]

Never use a while loop. While loops are current controlled. A for loop is voltage controlled. Use those.

Not if you are currently using it

[westfw]

assuming we're talking about microcontrollers, the constants are obviously always in flash.

You mean you WANT the constants to be in flash.  For instance, avr-gcc would happily put "const" variables in RAM (copied from flash at startup if they're initialized) and still treat them as "const" at the compiler level.  As you allude, on a microprocessor system, the compiler isn't going to have any idea which memory regions are flash (if there are any), and which are RAM (or ROM.)  On an x86, PPC, or ARM9 system (and many DSPs), "const" still has meaning as compile semantics, but you'll certainly have to go to extra effort if you really want some constants stored in a particular section of  a particular type of memory.

I'll have to admit to not knowing anything about automotive software methodology.  I'm a little surprised that calibration  constants aren't required to be in separate chips with well defined high level APIs protecting them...

[0xdeadbeef]

You mean you WANT the constants to be in flash.  For instance, avr-gcc would happily put "const" variables in RAM (copied from flash at startup if they're initialized) and still treat them as "const" at the compiler level.

Notice something? Then just re-read what I wrote.

I'll have to admit to not knowing anything about automotive software methodology.  I'm a little surprised that calibration  constants aren't required to be in separate chips with well defined high level APIs protecting them...

Not even in the times when the program was stored in EEPROM, they were in a separate "chip". They are located in a separate flash segment, so you can reprogram them independently.
Indeed, during development the mechanical engineers responsible for specific engine behavior change the calibration data during runtime by using tools that write to calibration RAM and the CPU switches between using constants from ROM or RAM (address line or SDA register trickery, specific overlay areas, nowadays mostly via MMU).

[Dinsdale]

Not if you are currently using it

Doh! Of course, you are correct. I see that you have a lot of potential.

[miguelvp]

Doh! Of course, you are correct. I see that you have a lot of potential.

Good one 
I'm glad that you didn't go into hysteresis, you are unlike others that get all saturated in these matters.

[Howardlong]

There are currently lots of potential differences on this thread. I don't know watt's going on, but susceptance to such behaviour should be met with resistance. Too much reactance going on IMHO.