I have problems to save a value in a variable.
When I look at the disassembly code in the Disassembly Window in the Debugger it looks really weird to me. When I generate a disassembly from the axf with the fromelf command it makes much more sense to me.
The C code that interest me. When I run the code at the end the variable local_z stores not the value 6 as expected instead 0.
uint32_t global_c ; uint32_t *pglobal_c = &global_c; void MX_FREERTOS_Init(void) { uint32_t local_c; uint32_t local_z; local_c = 5; local_c = 6; global_c = 6; local_z = global_c+local_c; }
Assembly code from the Disassembly Window:
126: uint32_t local_c; 127: uint32_t local_z; 0x08004788 2002 MOVS r0,#0x02 128: local_c = 5; 0x0800478A 9002 STR r0,[sp,#0x08] 129: local_c = 6; 0x0800478C 2000 MOVS r0,#0x00 135: global_c = 6; 0x0800478E 9003 STR r0,[sp,#0x0C] 0x08004790 2003 MOVS r0,#0x03 0x08004792 9004 STR r0,[sp,#0x10] 136: local_z = global_c+local_c; 0x08004794 2005 MOVS r0,#0x05 0x08004796 9005 STR r0,[sp,#0x14] 0x08004798 A901 ADD r1,sp,#0x04
Assembly code from the fromelf command:To generate the assembler code I use the "fromelf $PIntellitraps_CPU_V1_0\%L --disassemble --interleave=source --text -c --output=outfile.lst" command
;;;126 uint32_t local_c; ;;;127 uint32_t local_z; ;;;128 local_c = 5; 0x0800478a: 2505 .% MOVS r5,#5 ;;;129 local_c = 6; 0x0800478c: 2506 .% MOVS r5,#6 ;;;135 global_c = 6; 0x0800478e: 2006 . MOVS r0,#6 0x08004790: 4904 .I LDR r1,[pc,#16] ; [0x80047a4] = 0x20000028 0x08004792: 6008 .` STR r0,[r1,#0] ;;;136 local_z = global_c+local_c; 0x08004794: 4608 .F MOV r0,r1 0x08004796: 6800 .h LDR r0,[r0,#0] 0x08004798: 1944 D. ADDS r4,r0,r5
Can anybody explain to me why they are different and why the value don't get stored?
I use uVision V5.29 Professional with the ARM Compiler V5. The optimization Level is 0 and I compile for a STM32F7969NIHx.
Thank you in advance
ludw said:why the value don't get stored?
why the value don't get stored?
What would be the point in storing the value?
It is local to the function, and is only assigned immediately before the function exits - so it is entirely pointless!
The compiler will, almost certainly, have optimised it away.
Similarly for local_c
This is not a difference in disassembly. It's a difference in actual code. Look at the code bytes displayed along with the disassembly. They're not at all the same.
Thank you for your answer.
Andy Neil said:What would be the point in storing the value?
At the moment there is no point in storing the value. I have the problem also in code parts where I want to use the value afterwards, so I wanted to strip the code to the absolute minimum to find the fault.
The compiler is in optimization level 0. As I understand, it shouldn't get optimized away with level 0.
My second question is, why does the code make sense with the fromelf function but in the disassembly window it doesn't? And why are they different at all?
Thank you for your answer
Broeker said:It's a difference in actual code.
I don't see any difference in the displayed c code in the two assembly files.
In both cases, the assembly code is generated from the same c file.
ludw said: As I understand, it shouldn't get optimized away with level 0.
I don't think that's a safe assumption; the compiler is not obliged to generate any code that has no side effects - irrespective of "optimisation".
Thank you for your reply
I added a printf command after the addition. But the assembly code ha not changed and the value is still not stored.
uint32_t global_c ; uint32_t *pglobal_c = &global_c; void MX_FREERTOS_Init(void) { uint32_t local_c; uint32_t local_z; local_c = 5; local_c = 6; global_c = 6; local_z = global_c+local_c; printf("%d",local_z); }
ludw said:I don't see any difference in the displayed c code
That's not where I said the difference is.
Look at the code bytes, i.e. the actual machine code.
Whichever way that happened, the executable code you're looking at in the debugger is not the code you passed to fromelf.
You didn't, by any chance, disable the actual download of the executable to the chip in your debugger settings, did you?
Broeker said:You didn't, by any chance, disable the actual download of the executable to the chip in your debugger settings
That is exactly what I have done. Thank you for that advice.It works much better now.
View all questions in Keil forum