We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Greetings!
Keil uVision 5, ARM Compiler 6.12, -Os balanced, Cortex-M3. Just as an example
GPIOC->OR = (GPIOC->OR & ~0xFF) | 0x12; while(1) { u32 i = 100000; ... }
MOVS r1, #0x12 LDR r0, [r12, #0x00] BFI r0, r1, #0, #8 MOVW r1, #0x86A0 STR r0, [r12, #0x00] MOVT r1, #0x01
As you can see, there was a reordering of instructions. It is quite legal, I understand that perfectly.But how do you make the compiler not do this here? I want nothing superfluous to be wedged into the GPIOC->OR change
MOVS r1, #0x12 LDR r0, [r12, #0x00] BFI r0, r1, #0, #8 STR r0, [r12, #0x00] MOVW r1, #0x86A0 MOVT r1, #0x01
What optimizer barrier should I use and how?
Why would you want that? The compiler reorders the instructions to better fit the dual-issue pipeline (when two instructions can be executed simultaneously in the same clock cycle). So no time penalty is expected, just a performance increase. For a dual-issue pipeline, the first solution is better than yours as it saves one clock cycle.
Where are the two pipelines on the Cortex-M3?The question was not why I needed this, but whether the compiler tools could influence it.
You're right, I'm sorry, I missed that. You will probably need to implement this piece of code in inline assembly. I am not aware of any compiler directive that prevents the instructions from being reordered.
So I don't know, but I thought, after all, maybe there are such directives... Thank you!