Which is the more likely cause of three calls to volatileStore() with different addresses becoming three unique functions rather than three (load address, store value) couplets?
Candidate 1: the complicated use of `volatileStore()` inside a template nested in another template?
Candidate 2: the minisvd2nim tool creates a distinct type for each register and I estimate that is forcing distinct function calls for each volatileStore()?
Here's the ARM disassembled output of a typical LED blinky routine. Notice three calls to distinct volatileStore target. The first one sets the data direction register. The next two (in a loop) set/clear a GPIO pin.
00026130 <main__c2lora_u17>:
26130: b580 push {r7, lr}
26132: af00 add r7, sp, #0
26134: 2110 movs r1, #16
26136: 480a ldr r0, [pc, #40] @ (26160 <main__c2lora_u17+0x30>)
26138: f7ff ffb1 bl 2609e <volatileStore__OOZdepsZsvdZnrf52840Zp_u9608>
2613c: 2110 movs r1, #16
2613e: 4809 ldr r0, [pc, #36] @ (26164 <main__c2lora_u17+0x34>)
26140: f7ff ffbb bl 260ba <volatileStore__OOZdepsZsvdZnrf52840Zp_u7869>
26144: f44f 707a mov.w r0, #1000 @ 0x3e8
26148: f7ff ffc5 bl 260d6 <delay__c2lora_u3>
2614c: 2110 movs r1, #16
2614e: 4806 ldr r0, [pc, #24] @ (26168 <main__c2lora_u17+0x38>)
26150: f7ff ffe0 bl 26114 <volatileStore__OOZdepsZsvdZnrf52840Zp_u8335>
26154: f44f 707a mov.w r0, #1000 @ 0x3e8
26158: f7ff ffbd bl 260d6 <delay__c2lora_u3>
2615c: e7ee b.n 2613c <main__c2lora_u17+0xc>
2615e: bf00 nop
26160: 50000818 @ <UNDEFINED> instruction: 50000818
26164: 50000808 @ <UNDEFINED> instruction: 50000808
26168: 5000080c @ <UNDEFINED> instruction: 5000080cCandidate 3) the disassembly of the volatileStore() looks like it is dealing with 64-bit values rather than 32-bit values. The target is a 32-bit ARM (nrf52840):
00026114 <volatileStore__OOZdepsZsvdZnrf52840Zp_u8335>:
26114: b480 push {r7}
26116: b083 sub sp, #12
26118: af00 add r7, sp, #0
2611a: 6078 str r0, [r7, #4]
2611c: 6039 str r1, [r7, #0]
2611e: 687b ldr r3, [r7, #4]
26120: 683a ldr r2, [r7, #0]
26122: 601a str r2, [r3, #0]
26124: bf00 nop
26126: 370c adds r7, #12
26128: 46bd mov sp, r7
2612a: f85d 7b04 ldr.w r7, [sp], #4
2612e: 4770 bx lrThat's sorta odd behavior. First thing I'd check would be the Nim C output.
It may be a compiler bug (?) since volatileStore is marked inline. Nim should inline it directly IIRC before the C gen stage. Though you may want to try setting define:release as maybe only release inlines?
There's also the --expandMacros: (--expandMacro:?) flag that can be handy.