0xMiden / 0xMiden/miden-vm

Consider using an element index instead of word index for `dupw`

Open
#2,347 2 comments 1 reaction 0 assignees View on GitHub
assembly
Dominant language
Rust
Stars
772
Forks
352
Avg merge
1d 12h
Merged PRs (30d)
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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.