Skip to content

Tracking issue: flatten the eval stack #183

Open
@sorpaas

Description

@sorpaas

Currently, if core finds an opcode it cannot handle, it will Trap first, and then Runtime will attempt to eval it. This is rather inefficient.

Instead, core should expose the eval table (which is just 256-item fn pointers), to allow Runtime to customize it. Machine would now take a generic parameter stateS (with default ()), and then pass it as the final parameter to eval fns. Runtime then should fully build with that, and only trap for CALL/CREATE. Gasometer should be the only thing that wraps a Machine.

This should make it more predictable when reasoning about performance, while not losing much abstractions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions