Better implementation of caller instruction/operation

[bobbinth]

Current implementation of the caller instruction and support infrastructure has some limitations and may potentially be optimized to reduce the number of columns by 4.

First, the limitation of caller instruction (and the underlying operation) is that we can call it only in syscall context. It would be useful, however, to call it in other contexts as well.

Second, to support the caller operation, we add 4 columns to the system trace to keep track of the hash of the currently executing function. We also add in_syscall column to determine whether we are in a syscall or not. The in_syscall column is used for two primary purposes: (1) to figure out whether we can invoke the caller operation, and (2) whether we can invoke a syscall operation.

One potential way to simplify and improve this structure is to give special meaning to memory address $0$ in every context. Specifically, this memory address would hold the hash of the currently executing function. This would be instead of storing this value in the 4 columns of the system trace, and thus, we could eliminate 4 columns from the main trace.

To populate address $0$ with the hash of the currently executing function, we would need up update the logic of CALL and SYSCALL operations. These operations would now need to write the hash of the called function into memory. Thus, the operations would need to perform the following requests to the chiplet bus:

• CALL: 1 hasher request and 1 memory write request.
• SYSCALL, 1 hasher request, 1 kernel ROOM access request, and 1 memory write request.

I believe both of these should be fine as we still have some slack in constraint degrees involving these operations.

Next, we'll need to ensure that memory address $0$ is "read-only". This can be done by adding extra constraints to the operations which write to memory to make sure the address is in the valid range.

Finally, we'd need to update the CALLER operation to read memory address $0$ from the parent's context. To track the parent context, we'll need to add one column to the system trace - e.g., prnt_ctx. This column would be initialized to $0$ and would be updated by the CALL and SYSCALL operations.

With the above design we gain the following benefits:

• We can execute caller operation in every context (not just in syscall).
• We can also get the value of the currently executing function in every context.
• We reduce the number of columns by 3.

We can also probably get rid of in_syscall column. First, this column is no longer needed to check the validity of caller instructions. But we still need it to make sure syscalls can be made only from non-syscall contexts. We should be able to do this by enforcing that $ctx != 0$ whenever SYSCALL operation is executed. This constraint may require a helper value (inverse of $ctx$) - but i think we should be able to find a place for it.

Overall, if the above changes can be implemented, we'd reduce the size of the system trace from 8 columns to 4, and the new system trace layout would like like so:

   clk     ctx     prnt_ctx      fmp
├───────┴───────┴────────────┴────────┤

[bobbinth]

It probably makes sense to update #483 after this one is done.

[bobbinth]

Related issue #813.