memcpy() and volatile

[IanB]

This is a micro controller, so single thread. As I said the problem is that I need the compiler to not assume variables have not changed, basically to not try to optimize that, to do that I have to rewrite everything from what you say.

The compiler removing code is an optimization. If you don't want the compiler to do such optimizations, have you tried changing the optimization flags on the compiler?

[IanB]

So the whole problem was down to a variable that I set to a value in a function at start up. Having created it and assigned a value the compiler then decides that it does not apply any more (even when marked volatile) as it has not been changing and makes it 0 and then uses the variable in 4 calculations.

Defining it as const fixes it.

Are you sure it was not a scoping problem? It is possible for variables of a given name to "hide" other variables with the same name due to visible scope. It may therefore appear that after you assign a value to a variable that the value disappears on return from a function.

[Berni]

So the whole problem was down to a variable that I set to a value in a function at start up. Having created it and assigned a value the compiler then decides that it does not apply any more (even when marked volatile) as it has not been changing and makes it 0 and then uses the variable in 4 calculations.

Defining it as const fixes it.

That does sound like RAM being corrupted by something writing out of bounds. Often these are a real b***h to find, but since you have a variable you normally write once and it very repeatably gets trampled, this makes it easy to catch by simply placing a memory write breakpoint onto it. Whenever it breakpoints on code that does not look like it should be writing to it, you have your out of bounds corruption culprit.

[golden_labels]

So the whole problem was down to a variable that I set to a value in a function (…)Defining it as const fixes it.

That sounds like accidental hiding of a bug in code, not a fix.

Can you provide a minimal code reproducing the issue, preferably with the corresponding assembly output? And the compiler used, including version?

[Simon]

This is a micro controller, so single thread. As I said the problem is that I need the compiler to not assume variables have not changed, basically to not try to optimize that, to do that I have to rewrite everything from what you say.

The compiler removing code is an optimization. If you don't want the compiler to do such optimizations, have you tried changing the optimization flags on the compiler?

All of this trashing of my code has been done with no optimizations set. It is utterly ridiculous that clear and plain statements are just blatantly ignored. I'm sure it is not the first time I have been around this sort of stupid circuit, even volatile does naf all.

It is the standard compiler with microchip studio.

[Simon]

So the whole problem was down to a variable that I set to a value in a function (…)Defining it as const fixes it.

That sounds like accidental hiding of a bug in code, not a fix.

Can you provide a minimal code reproducing the issue, preferably with the corresponding assembly output? And the compiler used, including version?

Don't be silly, at this size of project sniff near it and it blows up in your face. It will be a task in itself to reproduce the error as a slimmed down version as that will completely change everything.

[Andy Watson]

So the whole problem was down to a variable that I set to a value in a function (…)Defining it as const fixes it.

Where, exactly have you declared the offending variable(s)? Some of your replies hint of a potential scope problem. If you can't show the code, could you atleast give a minimal outline.

[IanB]

All of this trashing of my code has been done with no optimizations set. It is utterly ridiculous that clear and plain statements are just blatantly ignored. I'm sure it is not the first time I have been around this sort of stupid circuit, even volatile does naf all.

It is the standard compiler with microchip studio.

Well, be careful with assumptions here. Typically a compiler will have some optimizations turned on by default. If you want no optimizations applied, you would normally have to explicitly turn them off, for example by using the "-O0" flag or whatever applies for the particular compiler.

"No optimizations set" is not the same thing as "Disable optimizations".

[gf]

Code: [Select]

void mymemcpy(void *dest, void *src, size_t n)
{
// Typecast src and dest addresses to (char *)
uint8_t *csrc = (uint8_t *)src;
uint8_t *cdest = (uint8_t *)dest;

// Copy contents of src[] to dest[]
for (uint8_t i=0; i<n; i++)
cdest[i] = csrc[i];
}


Why do you declare the loop variable uint8_t, and not size_t?
For n >= 256, it will loop vorever.

[SiliconWizard]

Code: [Select]

void mymemcpy(void *dest, void *src, size_t n)
{
// Typecast src and dest addresses to (char *)
uint8_t *csrc = (uint8_t *)src;
uint8_t *cdest = (uint8_t *)dest;

// Copy contents of src[] to dest[]
for (uint8_t i=0; i<n; i++)
cdest[i] = csrc[i];
}


Why do you declare the loop variable uint8_t, and not size_t?
For n >= 256, it will loop vorever.

Which is arguably fun.

[golden_labels]

All of this trashing of my code has been done with no optimizations set. It is utterly ridiculous that clear and plain statements are just blatantly ignored.

That response alone makes me believe, that there is a discrepancy between what the code actually means and what you believe it means. Which is very common, because C is a unexpectedly abstract language, falsely advertised as close to bare metal, and also horrendously complicated. Not only you wouldn’t be the first person to fall in this trap, but this happens to seasoned experts.

Of course I don’t press you to post any code. But in my eyes this fits the pattern of accidental hiding of a bug.

[brucehoult]

Code: [Select]

void mymemcpy(void *dest, void *src, size_t n)
{
// Typecast src and dest addresses to (char *)
uint8_t *csrc = (uint8_t *)src;
uint8_t *cdest = (uint8_t *)dest;

// Copy contents of src[] to dest[]
for (uint8_t i=0; i<n; i++)
cdest[i] = csrc[i];
}


Why do you declare the loop variable uint8_t, and not size_t?
For n >= 256, it will loop vorever.

Using uint8_t also makes the code less efficient because on a 32 bit machine it has to add (at least) an extra `uxtb` (or `and #0xFF` etc) to the loop.

[IanB]

Ok they used char variables, so I replaced with the more modern uint8_t

Why would you do that? uint8_t is not more modern, it is simply different.

"char" represents the basic storage unit of memory, which is appropriate when copying memory around. It is an amount of memory that can hold one character (memory size = 1).

"uint8_t" represents an unsigned integer exactly 8 bits long, which is appropriate when doing unsigned arithmetic with numbers that fit in the range 0 to 255.

Since memcpy is copying memory, it uses char, deliberately so. Changing a memory copy routine to work with numbers instead of the particular object specified to be one unit of memory does not make good sense.

[brucehoult]

Ok they used char variables, so I replaced with the more modern uint8_t

Why would you do that? uint8_t is not more modern, it is simply different.

"char" represents the basic storage unit of memory, which is appropriate when copying memory around. It is an amount of memory that can hold one character (memory size = 1).

"uint8_t" represents an unsigned integer exactly 8 bits long, which is appropriate when doing unsigned arithmetic with numbers that fit in the range 0 to 255.

Since memcpy is copying memory, it uses char, deliberately so. Changing a memory copy routine to work with numbers instead of the particular object specified to be one unit of memory does not make good sense.

Good point too. On a machine with bytes larger than 8 bits this will only copy the lower 8 bits of each byte, leaving 0s in the rest.

[Simon]

Code: [Select]

void mymemcpy(void *dest, void *src, size_t n)
{
// Typecast src and dest addresses to (char *)
uint8_t *csrc = (uint8_t *)src;
uint8_t *cdest = (uint8_t *)dest;

// Copy contents of src[] to dest[]
for (uint8_t i=0; i<n; i++)
cdest[i] = csrc[i];
}


Why do you declare the loop variable uint8_t, and not size_t?
For n >= 256, it will loop vorever.

Using uint8_t also makes the code less efficient because on a 32 bit machine it has to add (at least) an extra `uxtb` (or `and #0xFF` etc) to the loop.

OK so the original function I copied off the net used "char" or "int"  (can't remember), my compiler complained, so I changed to uint8_t to shut it up, in my mass renaming of memcpy() calls I also altered the header file that the original memcpy() is in so the compiler saw 2 definitions with different arguments pointing at size_t, before I figured this I changed that to uint8_t.

So I need to change that back to size_t. My copy operations are on only a few bytes at a time at most 4 but yes I should provide more scope to the function.

Using uint8_t also makes the code less efficient because on a 32 bit machine it has to add (at least) an extra `uxtb` (or `and #0xFF` etc) to the loop.

What does this mean? I'm interested. Are you saying that 16 bits is the smallest a 32 bit (ARM) machine will work with anyway? I am aware that an ARM0+ has the ability to transfer two peices af data on it's 32 bit bus at once due to the thumb instruction set (and that is as clever as I get) so I tend to not oversize variables where practical.

[Simon]

All of this trashing of my code has been done with no optimizations set. It is utterly ridiculous that clear and plain statements are just blatantly ignored.

That response alone makes me believe, that there is a discrepancy between what the code actually means and what you believe it means. Which is very common, because C is a unexpectedly abstract language, falsely advertised as close to bare metal, and also horrendously complicated. Not only you wouldn’t be the first person to fall in this trap, but this happens to seasoned experts.

Of course I don’t press you to post any code. But in my eyes this fits the pattern of accidental hiding of a bug.

Is C++ better in this respect? I have been trying to get started in it for a long time and it's a natural step.

[Simon]

So code wise. To simplify by ignoring the files that are not used with this variable.

I have a main.c file, a motor.c file and a motor.h file. motor.h is declared in main.c.

The variable is only defined in motor.c as "volatile int32_t nominal_current".

A function defined in motor.c and declared in motor.h has a line that says:

nominal_current = 28000 ;

The function which sets up other variables too that are possibly also being optimized out but not causing an issue is called in main() before while(1){main program loop}.

A function called control() defined in motor.c and declared in motor.h uses nominal_current in 4 calculations and is called in the while(1) loop in main()

So if I pause after the function has run to set the variable up it has a value of 28000, if I pause in the control() function it's value is now "0".

[Simon]

All of this trashing of my code has been done with no optimizations set. It is utterly ridiculous that clear and plain statements are just blatantly ignored. I'm sure it is not the first time I have been around this sort of stupid circuit, even volatile does naf all.

It is the standard compiler with microchip studio.

Well, be careful with assumptions here. Typically a compiler will have some optimizations turned on by default. If you want no optimizations applied, you would normally have to explicitly turn them off, for example by using the "-O0" flag or whatever applies for the particular compiler.

"No optimizations set" is not the same thing as "Disable optimizations".

Optimization is set to "none (-O0)" I realize that some optimization may be taking place but this seems be another problem.

[Simon]

These are the compiler options I don't know if I need the first two, for a micro controller application they sound like trouble.

[tggzzz]

All of this trashing of my code has been done with no optimizations set. It is utterly ridiculous that clear and plain statements are just blatantly ignored.

That response alone makes me believe, that there is a discrepancy between what the code actually means and what you believe it means. Which is very common, because C is a unexpectedly abstract language, falsely advertised as close to bare metal, and also horrendously complicated. Not only you wouldn’t be the first person to fall in this trap, but this happens to seasoned experts.

Of course I don’t press you to post any code. But in my eyes this fits the pattern of accidental hiding of a bug.

Is C++ better in this respect? I have been trying to get started in it for a long time and it's a natural step.

Read https://yosefk.com/c++fqa/index.html and you will have your answer. I particularly like the bit on "const", since I remember the C++ committee spending years discussing whether it should be possible or impossible to "cast away constness".

IMNSHO if you haven't fully grokked C, then C++ isn't for you.

[tggzzz]

All of this trashing of my code has been done with no optimizations set. It is utterly ridiculous that clear and plain statements are just blatantly ignored.

That response alone makes me believe, that there is a discrepancy between what the code actually means and what you believe it means. Which is very common, because C is a unexpectedly abstract language, falsely advertised as close to bare metal, and also horrendously complicated. Not only you wouldn’t be the first person to fall in this trap, but this happens to seasoned experts.

Of course I don’t press you to post any code. But in my eyes this fits the pattern of accidental hiding of a bug.

Precisely, in all respects.

[Siwastaja]

I also get warnings where I use pointers, again unavoidable.

Add -Werror on command line, problem solved. Now you have to fix your code for it to compile.

[Siwastaja]

So the whole problem was down to a variable that I set to a value in a function at start up. Having created it and assigned a value the compiler then decides that it does not apply any more (even when marked volatile) as it has not been changing and makes it 0 and then uses the variable in 4 calculations.

Defining it as const fixes it.

This sounds like a broken compiler. Can you show any code?

Compilers are rarely broken. Knowing the history of this poster, it is not very good idea to suggest that. The code probably has large issues with the very basics all over it, and any random change is going to trigger a random observation of something "starting to work" or "stopping from working". As we never get any code, it isn't very helpful to reply to these threads.

[Siwastaja]

The compiler removing code is an optimization. If you don't want the compiler to do such optimizations, have you tried changing the optimization flags on the compiler?

Do not even suggest this. This is NEVER the solution. Code needs to be fixed instead. Compiler never removes code which has a purpose in the C abstract machine (except for rare cases of actual compiler bugs).

[Simon]

So a new problem cropped up, same thing, variable being ignored at random. Making it "static" solves this. The variable in only used in this one C file. So why look at code anywhere else to determine it's usefulness ?