PEGO

M070: Predecoded VM Match Data

A VM module stores literal strings and class descriptions. Converting those strings to runes/bytes or preparing ASCII class membership on every instruction would repeat setup work.

Mechanism and Invariants

buildVMProgram resolves the module's strings into reusable rune and byte literal arrays and builds ASCII masks for its classes. Literal and class instructions reference this prepared data. The original module and its descriptions still determine diagnostics; non-ASCII classes retain exact range checks. Recursive and iterative prepared programs are separate, so preparation is reusable within each selected backend.

Scope and State

Default setup for recursive and iterative VMs only. Closure captures its own matcher data; generated parsers emit theirs. Their analogous representations are covered by class/literal mechanisms, not this VM preparation step.

Reference Control

No private same-source per-instruction-conversion reference is maintained. This is setup work with matching consumers, unlike a parse-time optimization flag.

Evidence and Implementation

Records 017 and 032 measure ASCII class testing and literal matching respectively. They support the consumers but do not isolate predecoding itself from a repeated-conversion reference. No separate effect estimate is available.

Evidence records: 017, 032.

Source owners: buildVMProgram, vmProgram.runes, bytes and ascii, iterative VM literal/class execution.

The comparison policy distinguishes same-source controls, historical changes and full checkpoints.

Related mechanisms: M020, M030, G020.

Optimization Catalog