* Combine mstore_general and mload_general into one flag
* Add comments and make stack constraints cleaner.
* Fix number of native instructions
* Ordering
* Cleanup
* Update calls to stack eval from latest main
---------
Co-authored-by: Robin Salen <salenrobin@gmail.com>
* Combine FP254 flags
* Combine basic binary ops together and do CTL with opcode value
* Combine ternary ops together
* Combine MUL DIV and MOD
* Combine shift operations
* Combine byte with other binary ops
* Fix tests
* Clean leftover comment
* Update from latest main
* Put the 'is_simulated' flag inside the Operation enum
* Cleaner way to handle "simulated" operations SHL and SHR.
* Fix comments.
* Minor: suggestion for re-expressing `combined_ops`.
* Update comment
---------
Co-authored-by: Hamish Ivey-Law <hamish@ivey-law.name>
- `GET_STATE_ROOT` and `SET_STATE_ROOT` deal with the root of the state trie, and will be called from storage routines. Similarly `GET_RECEIPT_ROOT` and `SET_RECEIPT_ROOT` deal with the root of the receipt trie.
- `PANIC` enables an unsatisfiable constraint, so no proof can be generated.
- `GET_CONTEXT` and `SET_CONTEXT`, used when calling and returning
- `CONSUME_GAS` charges the sender gas; useful for cases where gas calculations are nontrivial and best implemented in assembly.
- `EXIT_KERNEL` simply clears the CPU flag indicating that we're in kernel mode; it would be used just before a jump to return to the (userspace) caller.
- `MLOAD_GENERAL` and `MSTORE_GENERAL` are for reading and writing memory, but they're not limited to the main memory segment of the current context; they can access any context and any segment. I added a couple macros to show how the they would typically be used.
There may be more later, but these are the ones I think we need for now. I tried to fill in smaller invalid sections of the decoder's tree, as Jacqui suggested, while keeping related opcodes together. We can fine tune it when the opcode list is more stable.
These are all intended to be priviledged, i.e. they will be treated as invalid if used from userspace, for compatibility as well as (in some cases) security reasons.
It seems redundant in most contexts, e.g. `use plonky2::field::extension_field::Extendable;`. One could import `extension_field`, but it's not that common in Rust, and `field::extension` is now about as short.
