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

Refactor interpreter package so we can reuse built-in operations in VM #3693

Open
Tracked by #3692
turbolent opened this issue Nov 22, 2024 · 0 comments
Open
Tracked by #3692

Comments

@turbolent
Copy link
Member

turbolent commented Nov 22, 2024

We are evaluating how Cadence programs can be executed using an alternative approach, namely compilation (code generation). Programs executed using the alternative approach must behave exactly like the current approach, interpretation using the interpreter.

Currently the implementation of the majority of the built-in functionality of Cadence is part of the package implementing the interpreter, interpreter. The implementation is also tightly coupled to the interpreter.

If we can find a way to decouple the built-in functionality from the interpreter, we can reuse it for the alternative execution approach, and do not have to re-implement the functionality, which is a lot of work, and very difficult to get correct, as it must function exactly like the existing solution.

Decouple and define (an) interface(s) for the following components, so they can be reused outside of the interpreter:

  • Values (interpreter.Value and implementations)
  • Static types (interpreter.StaticType and implementations)
  • Encoding (encode.go and decode.go)

This is difficult, as values are tightly coupled to the interpreter (most functions of the values get passed the full interpreter).

We might want to refactor the code gradually instead of all parts all at once.

interpreter.Value methods depend on the Interpreter for the following categories of operations, for example:

  • Metering of computation: ReportComputation
  • Metering of memory usage: MeterMemory
  • Get configuration: for example to determine if feature is enabled (e.g. tracing), invoke callbacks, etc.
  • Tracing: e.g. reportDictionaryValueDestroyTrace
  • Resource tracking: e.g. withResourceDestruction
  • Reference tracking: e.g. invalidateReferencedResources
  • Function value invocation: e.g. invokeFunctionValue
  • Storage writes: e.g. WriteStored, RemoveReferencedSlab
  • Storage reads: e.g. ReadStored
  • Ensure invariants: e.g. withMutationPrevention
  • Atree validation: e.g. maybeValidateAtreeValue, maybeValidateAtreeStorage
  • Static type conversion and validation: e.g. MustConvertStaticToSemaType, ExpectType, checkContainerMutation
  • etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant