Consider using an element index instead of word index for `dupw`
- Langage dominant
- Rust
- Étoiles
- 772
- Forks
- 352
- Merge moyen
- 1 j 12 h
- PR mergées (30 j)
- 93
Description
I wonder if it would make sense to refactor `dupw.n` so that `n` can be in range `0..=12` (as opposed to the current `0..=3`). It would then duplicate the word starting at the _element index_ `n` instead of the _word index_. I believe this would conceptually follow the recent refactor of `ProcessState::get_stack_word` that took a [word index in `0.17`](https://docs.rs/miden-processor/0.17.2/miden_processor/enum.ProcessState.html#method.get_stack_word) and takes an [element index](https://docs.rs/miden-processor/0.19.1/miden_processor/enum.ProcessState.html#method.get_stack_word_be) in the latest version.
The scenarios where this is useful is when you have a stack like this:
```
# => [num_inputs_start_ptr, num_inputs_end_ptr, INPUTS_COMMITMENT]
```
And you want to duplicate `INPUTS_COMMITMENT`. It's easy to do `dup.5 dup.5 dup.5 dup.5`, but `dupw.2` would just be more concise.
I think this would make `dupw` strictly more useful and all existing usages still work, by multiplying the previous `n` by 4.
But, it could be that I'm missing why this is not already allowed, so this is just a suggestion from a MASM user perspective.
Also, for consistency, I guess this should then also apply to other word instructions like `movupw` or `swapw`, but this then sounds like a much bigger refactor. So, if this is an unrealistic request, feel free to close the issue.
Guide de contribution
Ouvrir le guide de contribution
Évaluation
Cette issue n'a pas encore été évaluée.