= Solution
Keep `total` in the <callee-saved register> `r4`, and the first returned <sum> in the <callee-saved register> `r5`. Suppose the surrounding function has made an aligned <stack frame> with the local seven-halfword <array> at the current `sp`, occupying fourteen bytes in a sixteen-byte slot. One possible frame setup is `push {r4,r5,r6,lr}` followed by `sub sp,sp,#16`; the earlier code initializes `total`, `regular`, and `special` before this fragment.
``
ldr r0, =regular @ assembler literal load of the global array address
movs r1, #7
bl sum16
movs r5, r0 @ first sum must survive the next call
add r0, sp, #0 @ current frame's local special array
movs r1, #7
bl sum16
muls r0, r5, r0 @ second sum times first sum
adds r4, r4, r0 @ update total
``
The <AAPCS32> permits each call to overwrite `r0`–`r3`, `r12`, and condition flags, but requires preservation of `r4`–`r8`, `r10`, `r11`, and `sp`. Thus both `r4` and `r5` remain valid even if `sum16` is replaced by another conforming implementation. `bl` changes the link <processor register> `lr`, so the enclosing function saves its own return address in its prologue. Its epilogue can use `add sp,sp,#16` and `pop {r4,r5,r6,pc}`. The frame uses thirty-two bytes in total, preserving the required eight-byte <stack pointer> alignment at both calls.<Procedure Call Standard for the Arm Architecture by ARM Limited>[Sections 6.1.1, 6.2.1.2 and 6.4: scratch/preserved registers, public-interface alignment and word return]{ref}
The two calls may be evaluated in this order. Assume the product and final addition fit the signed 32-<bit> result expected by the source program; unlike each individual seven-element <sum>, their product need not fit. The <assembly language> operations retain their low 32 <bits> if this assumption fails, whereas signed <integer overflow> in the <C programming language> has different semantics.
Back to article page
