Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove queued_requests from the hasher #446

Closed
Tracked by #603
tohrnii opened this issue Oct 25, 2022 · 1 comment
Closed
Tracked by #603

Remove queued_requests from the hasher #446

tohrnii opened this issue Oct 25, 2022 · 1 comment
Labels
processor Related to Miden VM processor
Milestone

Comments

@tohrnii
Copy link
Contributor

tohrnii commented Oct 25, 2022

Currently, the entire hash computation is done when the decoder makes its initialization request and all intermediate lookups required for the correctness of $b_{chip}$ are queued. When the decoder needs subsequent lookups (e.g. as it absorbs new operations during RESPAN or when the completes code blocks and needs the return hash), it sends a request, and they are dequeued and sent to the $b_{chip}$ bus.

Instead, it might be better to compute the lookups at the time they are needed.

Solution proposed by @bobbinth:

The entire trace for a span block would still be computed as a part of the Hasher::hash_span_block(). But this method would not create any lookups. Instead, the HasherLookupContext::Start lookup would be created in Chiplets::hash_span_block(), and all other lookups would be created by Chiplets::absorb_span_batch() and Chiplets::read_hash_result() (though, we'd probably need to have a specialized version of this method for SPAN blocks).

There is a bit more complexity here as Decoder::respan() doesn't have access to the address of the batch being executed but I think it shouldn't be too complicated to provide this info to this method, and once it is there, other parts should be relatively straight-forward.

So, the Hasher would no longer be responsible for computing lookups, and that responsibility would move into hasher-related Chiplets methods.

For control blocks, the solution should be relatively simple:

  1. At the time when control block execution ends, the decoder knows the address of the block (which it received from the hasher at the time when block hash is computed). We would need to update some method signatures in the decoder to propagate this info back to end_join_block(), end_split_block() etc. methods.
  2. We can then pass this address into Chiplets::read_hash_result() method, and that should be enough to compute a lookup for the return value (addr for the lookup would be addr of the block + 7).
@bobbinth
Copy link
Contributor

No longer relevant after #1140.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
processor Related to Miden VM processor
Projects
Status: Done
Development

No branches or pull requests

3 participants