Author Topic: memcpy() and volatile  (Read 7034 times)

0 Members and 1 Guest are viewing this topic.

Online IanB

  • Super Contributor
  • ***
  • Posts: 11980
  • Country: us
Re: memcpy() and volatile
« Reply #25 on: April 09, 2024, 04:14:41 pm »
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?
 

Online IanB

  • Super Contributor
  • ***
  • Posts: 11980
  • Country: us
Re: memcpy() and volatile
« Reply #26 on: April 09, 2024, 04:17:48 pm »
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.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4997
  • Country: si
Re: memcpy() and volatile
« Reply #27 on: April 09, 2024, 04:27:19 pm »
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.
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 1261
  • Country: pl
Re: memcpy() and volatile
« Reply #28 on: April 09, 2024, 05:30:51 pm »
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?


People imagine AI as T1000. What we got so far is glorified T9.
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #29 on: April 09, 2024, 08:25:32 pm »
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.
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #30 on: April 09, 2024, 08:28:03 pm »
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.
 

Online Andy Watson

  • Super Contributor
  • ***
  • Posts: 2100
Re: memcpy() and volatile
« Reply #31 on: April 09, 2024, 08:53:20 pm »
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.
 

Online IanB

  • Super Contributor
  • ***
  • Posts: 11980
  • Country: us
Re: memcpy() and volatile
« Reply #32 on: April 09, 2024, 09:06:35 pm »
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".
 
The following users thanked this post: SiliconWizard

Online gf

  • Super Contributor
  • ***
  • Posts: 1298
  • Country: de
Re: memcpy() and volatile
« Reply #33 on: April 09, 2024, 09:14:05 pm »
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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14695
  • Country: fr
Re: memcpy() and volatile
« Reply #34 on: April 09, 2024, 10:29:47 pm »
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.
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 1261
  • Country: pl
Re: memcpy() and volatile
« Reply #35 on: April 09, 2024, 10:42:38 pm »
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.
People imagine AI as T1000. What we got so far is glorified T9.
 
The following users thanked this post: newbrain

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4109
  • Country: nz
Re: memcpy() and volatile
« Reply #36 on: April 09, 2024, 11:52:15 pm »
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.
 

Online IanB

  • Super Contributor
  • ***
  • Posts: 11980
  • Country: us
Re: memcpy() and volatile
« Reply #37 on: April 10, 2024, 12:12:24 am »
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.

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4109
  • Country: nz
Re: memcpy() and volatile
« Reply #38 on: April 10, 2024, 12:19:59 am »
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.
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #39 on: April 10, 2024, 07:30:28 am »
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.

Quote

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.
« Last Edit: April 10, 2024, 07:45:36 am by Simon »
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #40 on: April 10, 2024, 07:31:33 am »
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.
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #41 on: April 10, 2024, 07:41:55 am »
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".
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #42 on: April 10, 2024, 07:49:07 am »
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.
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #43 on: April 10, 2024, 07:53:56 am »
These are the compiler options I don't know if I need the first two, for a micro controller application they sound like trouble.



2110829-0
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19846
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: memcpy() and volatile
« Reply #44 on: April 10, 2024, 08:17:23 am »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19846
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: memcpy() and volatile
« Reply #45 on: April 10, 2024, 08:19:08 am »
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8250
  • Country: fi
Re: memcpy() and volatile
« Reply #46 on: April 10, 2024, 08:34:33 am »
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.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8250
  • Country: fi
Re: memcpy() and volatile
« Reply #47 on: April 10, 2024, 08:40:24 am »
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.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8250
  • Country: fi
Re: memcpy() and volatile
« Reply #48 on: April 10, 2024, 08:42:06 am »
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).
 

Online SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 17854
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: memcpy() and volatile
« Reply #49 on: April 10, 2024, 09:08:44 am »
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 ?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf