On Friday, 21 July 2017 at 23:44:53 UTC, Mike wrote:
I'm getting broken binaries with -O2 and -O3. I've nailed the
culprit down to -fschedule-insns (i.e. if I add
-fno-schedule-insns to -O2 or -O3, the binary works fine).
I disassembled '-O2' and '-O2 -fno-schedule-insns' and compared
them, but they were quite different all the way through. No
only because of address locations, but also different registers
and even different opcodes. (e.g. 'str r2, [sp, #12]' vs 'strd
r1, r2, [sp, #8]')
Interestingly, I added a stategically placed `asm { "nop"; }` and
my binary was able to execute further. Comparing the disassembly
of the function I modified still showed quite a significant
difference.
Working Binary
-------------
ldr r2, [pc, #188] ; (8000c50 <hardwareInit+0x104>)
ldr r1, [pc, #188] ; (8000c54 <hardwareInit+0x108>)
ldr r3, [r2, #0]
and.w r3, r3, #780 ; 0x30c
orr.w r3, r3, #37888 ; 0x9400
movs r0, #0
str r3, [r2, #0]
strb r0, [r1, #0]
;-------------------------------------------------------
nop ; My stategically placed nop
;-------------------------------------------------------
ldr r3, [pc, #172] ; (8000c58 <hardwareInit+0x10c>)
ldr r0, [pc, #176] ; (8000c5c <hardwareInit+0x110>)
ldr r4, [pc, #176] ; (8000c60 <hardwareInit+0x114>)
ldr r2, [pc, #180] ; (8000c64 <hardwareInit+0x118>)
movs r1, #1
strb r1, [r3, #0]
ldr r3, [r0, #0]
orr.w r3, r3, #49152 ; 0xc000
str r3, [r0, #0]
strb r1, [r4, #0]
Not Working Binary
------------------
ldr r0, [pc, #184] ; (8000c4c <hardwareInit+0x100>)
ldr r1, [pc, #184] ; (8000c50 <hardwareInit+0x104>)
ldr r2, [pc, #188] ; (8000c54 <hardwareInit+0x108>)
ldr r3, [r1, #0]
ldr r4, [pc, #188] ; (8000c58 <hardwareInit+0x10c>)
movs r5, #0
strb r5, [r0, #0]
movs r0, #1
strb r0, [r2, #0]
ldr r2, [r4, #0]
ldr r5, [pc, #180] ; (8000c5c <hardwareInit+0x110>)
orr.w r2, r2, #49152 ; 0xc000
and.w r3, r3, #780 ; 0x30c
str r2, [r4, #0]
orr.w r3, r3, #37888 ; 0x9400
ldr r2, [pc, #168] ; (8000c60 <hardwareInit+0x114>)
strb r0, [r5, #0]
str r3, [r1, #0]
By "Not Working" I mean this code gets stuck in the while loop
PWR.CR.ODEN.value = true;
while(!PWR.CSR.ODRDY.value) { }
This is simply setting the "Overdrive Enable" register on the
power control peripheral of my hardware. The documentation
states:
To set or reset the ODEN bit, the HSI or HSE must be selected as
system clock.
I'm setting the HSI prior to setting ODEN, but it appears that
maybe the compiler is reordering the instructions. I still need
to investigate that further, but hopefully that provides a little
more insight.
Mike
