Where is all of the interpreter/debugger's state?

[KarlJoad]

I am tinkering with a project right now and need to find all for the component being interpreted/debugged. After reading through the interp library's code, and running through a few of the example tests, it seems that:

1. Every component gets an interpreter, which contains either a control or structural interpreter.
2. The only state an interpreter needs comes from the InterpreterState struct.

Is that assessment correct?

Currently, the goal is to just write a trace of the interpreter state to disk, perhaps by extending the struct with a serde derivation.

[EclecticGriffin]

Hi there! I'm the Cider (interpreter/debugger) person, so feel free to direct all your questions or wrath in my direction.

Off the top it is worth mentioning that you are asking about the Cider 1 code which is soon to be removed---possibly by the end of the week if I code fast---in favor of the Cider 2 architecture (currently lives under the flattened directory in interp).

So to answer your questions: Your assessment is correct. I've offered a few elaborations on the given points.

Every component gets an interpreter, which contains either a control or structural interpreter.

Yup! Every component instance is one of these two depending on how it is defined. These interpreter objects implement the same trait interface as primitives, so components that own components are oblivious to whether their cells are primitives from the standard library or are themselves Calyx components.

The only state an interpreter needs comes from the InterpreterState struct.

Yup, everything lives there in the cell_map and port_map. Everything else is basically bookkeeping. Worth noting that InterpreterState belongs implicitly to a single component instance with the control flow (or lack thereof) instantiated by the various "control" interpreters (or structural interpreters).

Can you tell me a bit more about what state you're hoping to trace?

[EclecticGriffin]

Ah, understood. So unfortunately that feature won't really be possible with the way Cider 1 works since ports and cells are keyed based on their raw pointers (i.e. memory location) from the IR which won't be deserializable. But the good news is that the Cider 2 redesign deliberately enables save/load mechanics. I've yet to implement that feature but I'll bump it up my list once the Cider 1 removal is finished.

In the meantime you can take a look at the program state for Cider 2 here: https://github.com/calyxir/calyx/blob/main/interp/src/flatten/structures/environment/env.rs#L218.

Unlike Cider 1, this Environment holds the entire program state, not just a single component and everything is laid out using vectors keyed by stable indexes.

[rachitnigam]

@KarlJoad this seems like an interesting direction! Perhaps it would be useful to schedule a short meeting with @EclecticGriffin and others to get a sense of where Cider 2 is going and how it can be aligned to meet your needs as well/how you could contribute to the developing code base?

[EclecticGriffin]

Yup, happy to schedule a meeting if that would be helpful!

[KarlJoad]

Ah... Ok. I did not see/realize that the ports and cells in the Interpreter was reliant on the IR's raw pointer values in-memory. That would make the serdes step complicated, for sure.

I will definitely start looking at Cider 2, especially if you are releasing it in the next few weeks.

Definitely! I'm available for a meeting most days during the summer. Right now I am just toying with a project idea, so I am not 100% sure what my needs are quite yet.

[EclecticGriffin]

Cool! Just shoot me an email and we can get something on the calendar