Variable length procedure locals

[hackaugusto]

Currently the number of locals of a procedure is static, and defined during the procedure declaration. This does enable one use-case: It allows procedures to use more than 16 elements of state by spilling data to memory, without cloberring state from the rest of the VM.

I think that is useful for procedures generated by an optimizing compiler, were multiple procedures are inlined and a larger number of registers are necessary. However this is limited to a predetermined size, defined at assembly time, meaning that variable length data, which could be provided by non-deterministic inputs, or from some recursive algorithms over variable length data, don't fit neatly on this model.

Since the opcodes are implements by a pointer register, if we can make a few modifications to the features I think it would be useful on more situations. Here are the changes I propose:

• Since the feature is implemented with a "stack pointer" (fmp), exposing the instructions to modify it would allow for usage like an stack pointer on popular architectures, which should make possible to use recursive algorithms (here I don't mean recursion in the VM, but recursion algorithms translate to an iterative loop)
• Guarantee that the memory is allocated sequentially (I believe this is the case already)
• Change the instructions that operate over the local variables to also accept stack values, instead of only immediates

[bobbinth]

This could be interesting, though we should think through the mechanics of how this can be implemented in the VM, and also consider what other alternatives (e.g., proper heap memory) could be used instead.

For context, the current approach is modeled after WASM where a function can have a fixed number of locals and all dynamic memory management is left to the user code.

Assuming we want to support a new instruction which allows to dynamically increase the number of locals (e.g., locgrow), the main question is where to store the current number of locals. This is not an issue with the current approach because the number of locals is known statically. But if this number can change dynamically, the we need to keep track of it at runtime. A couple of options which come to mind:

1. Keep it at a well-defined location in memory (e.g., at fmp address).
2. Keep it in a dedicated register.

Both of these approaches have tradeoffs and we'll need to think through them.