fix: further stack reductions for nanox support

[ryankurte]

it turns out the nanox has a more severe stack use limitation, faulting on -memory access- when the stack pointer exceeds 8k, rather than only when invoking syscalls on the nanosplus.

it is expected that this limit will be resolved in future firmware, for now we should be able to avoid the issue by pre-allocating and using out-pointer tricks to avoid rust's lack of working copy elision / NRVO.

following #23, this PR:

• refactors events to be self contained (simplifying passing these by reference)
• moves ui, event, and object storage to the heap w/ pointer-based initialisation
• splits out identity and key image functions so these can no-longer be inlined in Engine::update

this reduces our worst-case stack depth by ~2k down to ~7524 bytes which appears to get us under the limit on the nanox. this seems to be okay in the simulator, however, needs to be validated on an actual device.

[eranrund]

I'm curious, how does no-inlining help reduce stack usage?

[eranrund]

Changes all look good to me. I'd still like to understand how no inlining helps here.
Thanks!

[ryankurte]

thanks for the review!

I'm curious, how does no-inlining help reduce stack usage?

so LLVM's optimiser really likes to inline functions which makes a lot of sense for performance, but when you inline functions the stack frames get merged. say you have two functions called sequentially that both use 4k of local storage, when inlined that becomes 8k in the caller stack frame whereas non-inlined they'll each have their own 4k frame and when called sequentially will re-use the same (SP+4k) space on the stack.

none of this usually matters that much but it's exacerbated by rust not yet having working copy elision / NRVO and the rather severe 8k limit on the stack pointer (vs. ~20k of available memory) in the nanox OS.

[eranrund]

thanks for the review!

I'm curious, how does no-inlining help reduce stack usage?

so LLVM's optimiser really likes to inline functions which makes a lot of sense for performance, but when you inline functions the stack frames get merged. say you have two functions called sequentially that both use 4k of local storage, when inlined that becomes 8k in the caller stack frame whereas non-inlined they'll each have their own 4k frame and when called sequentially will re-use the same (SP+4k) space on the stack.

none of this usually matters that much but it's exacerbated by rust not yet having working copy elision / NRVO and the rather severe 8k limit on the stack pointer (vs. ~20k of available memory) in the nanox OS.

Gotcha, thanks for explaining!