[Interpreter] Indexed IR and flattening the interpreter state

[EclecticGriffin]

Related to #1051. Discussion of IR changes can be had on that discussion thread. Supposing the existence of a variant Indexed IR for the interpreter, or a general move to an indexed/unstructured IR CFG, lets consider changes to the interpreter.

A non-structured control program would potentially let the interpreter be less recursive in its core interpretation algorithms as rather than performing recursive calls down the entire active tree, the program stack could instead be represented explicitly as a stack of indexes into the control program and their associated state machines.

A related concern is whether or not it is possible to flatten the interpreter environment such that all ports, cell-state, and program counters are in a single environment rather than having sub-components hold an entire state-map inside themselves. This would make it generally easier to inspect all state and in particular greatly streamline working with deeply nested components. Having an environment structure entirely detached from the interpretation mechanisms would also make it easier to handle time-travel debugging & check-pointing in the debugger.

There are a few issues that make this more complicated.

• Cells need an arbitrary notion of internal state
• IR constructs are operate on definitions rather than instances, so port definitions need to be mapped back to their appropriate context

The above suggests that component instances require a mapping from their ports & cells to the appropriate value/state indices.

State:

• Vec of port values (i.e. mapping from port indexes to values)
• Vec of cell state
• Vec/set of program counters (stacks of control indices)

Cell State:

• primitive state
  | index to reg or reg
  | index/reference to memory
  | other (mult/div buffers)
  | empty (combinational only)
• component state (immutable ?)
  • map from ports to indices (immutable)
  • map from cells to indices (immutable)
  • index/pointer to program counter (immutable)

This adds more explicit indirection which previously happened via objects and pointers. This also allows a form of JITing where groups could be "compiled" for a specific component instance by creating an alternate set of assignments which use the direct port and cell indices.

[rachitnigam]

Really exciting overview! I think the flat IR makes a lot of sense overall and using it within Cider could be a good demonstration of its utility for the overall infrastructure. I think one way to pitch this whole effort, as summarized by @sampsyo, is that it makes the interpreter more maintainable and extensible. Implement the @sync semantics or implementing a symbolic executor on top of it could be a good milestone to demonstrate the extensibility