Local procedure memory overwrites memory from outer context about miden-vm HOT 3 CLOSED

I think given the current specs, this behavior is correct - but I see how this can be very confusing. The issue is that script context does not have any locals and for procedures fmp always starts at 0 - so, they overlap. There are a couple of ways to address this:

1. We can allow locals in the script context as well - e.g., via begin.4 or something like that.
2. We can set the initial value of fmp to something other than 0.

If we go with the second option (which I think might be a better approach), the next question would be: what should the initial offset be? One option is: 2^32 - 1.

This would mean that the segment of "global memory" which doesn't overlap with local memory of procedures is roughly 2^32 - 1 words, which should be more than sufficient for any program. The reason why we don't want to make it even bigger is that we have a constraint against memory addresses which says that memory addresses accessed during program execution must be at most 2^32 - 1 values apart. Thus, if we make the offset bigger, and the program doesn't do anything with the global memory, the offset could cause a fault.

In fact, it may be safer to set the offset to something like 2^30. This still provides enough "global memory" and would also safeguard against cases when procedures declare locals but don't end up using them.

An alternative approach is to always output the first operation of a program to be something that pushes zeros to memory address 2^32 - 1. And then we can make the offset 2^32 or even greater (and we won't run into faults) - but I'm not sure this is worth it.

from miden-vm.

I think given the current specs, this behavior is correct

Yeah, I've been thinking about it more & I agree, but I think it's very unexpected behaviour from a user perspective & should probably be adjusted.

We can set the initial value of fmp to something other than 0.

This would be my preference. It seems more flexible and easier to work with than requiring locals to be declared in the script context.

In fact, it may be safer to set the offset to something like 2^30. This still provides enough "global memory" and would also safeguard against cases when procedures declare locals but don't end up using them.

Yeah, I think we should plan for that case. Using offset 2^30 seems like the best option to me.

An alternative approach is to always output the first operation of a program to be something that pushes zeros to memory address 2^32 - 1. And then we can make the offset 2^32 or even greater (and we won't run into faults) - but I'm not sure this is worth it.

This doesn't seem worth it, since it seems unlikely that the option above will be problematic. If we really run into cases where so much memory is being used that we need a bigger offset, we could make this adjustment.

from miden-vm.

Closed by #124

from miden-vm.