0xMiden / 0xMiden/miden-vm

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

未关闭
#2,347 2 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看
assembly
主要语言
Rust
星标
772
派生
352
平均合并
1 天 12 小时
30 天内合并 PR
93

描述

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.

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。