Skip to content

feat: traits for generalized E3 #1664

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

Open
wants to merge 10 commits into
base: feat/new-execution-e4
Choose a base branch
from

Conversation

jonathanpwang
Copy link
Contributor

@jonathanpwang jonathanpwang commented May 20, 2025

This is targeting a new branch feat/new-execution-e4 which we should merge into feat/new-execution only after we get everything compiling again.

Review this only after all E1/2/3 tasks are resolved and "E4" becomes a blocker.

This PR introduces the traits necessary to unify E3 and what we were formerly calling E4 into a single E3 generic over a new concept of RecordArena. Basically RecordArena is a virtual allocator for records, which is backed by either the RowMajorMatrix itself or a more compact raw byte buffer (the latter is for hardware acceleration purposes).

As discussed offline, the NewVmChipWrapper struct no longer makes sense and we should move RecordArena parts into CTX. For now I made do by making some traits specific to RowMajorMatrix-backed arenas -- these can be changed later as needed.

I included one example of Rv32BaseAlu all compiled and working. Unfortunately everything else no longer compiles.

My thinking is we can merge this first and then @arayikhalatyan can speed-run the switching of most of the traits to get everything compiling again, and then we can re-run tests to make everything still works. (The alternative to get things to compile incrementally seems more painful?)

closes INT-3969

Comment on lines +294 to +295
// PERF: needless conversion
let local_opcode = BaseAluOpcode::from_usize(record.local_opcode as usize);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do this in almost all the chips to assert that the opcode provided is valid. I am for letting the chips assume the opcode is valid and removing the unnecessary conversions from all the chips.

Comment on lines +175 to 176
/// fill in the rest of the row. This function will be called for each row in the trace which
/// being used, and all other rows in the trace will be filled with zeroes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// fill in the rest of the row. This function will be called for each row in the trace which
/// being used, and all other rows in the trace will be filled with zeroes.
/// fill in the rest of the row. This function will be called for each row in the trace which
/// is being used, and for all other rows in the trace see `fill_dummy_trace_row`.

@arayikhalatyan arayikhalatyan self-requested a review May 23, 2025 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants