doc.odin 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175
  1. /*
  2. package regex_vm implements a threaded virtual machine for interpreting
  3. regular expressions, based on the designs described by Russ Cox and attributed
  4. to both Ken Thompson and Rob Pike.
  5. The virtual machine executes all threads in lock step, i.e. the string pointer
  6. does not advance until all threads have finished processing the current rune.
  7. The algorithm does not look backwards.
  8. Threads merge when splitting or jumping to positions already visited by another
  9. thread, based on the observation that each thread having visited one PC
  10. (Program Counter) state will execute identically to the previous thread.
  11. Each thread keeps a save state of its capture groups, and thread priority is
  12. used to allow higher precedence operations to complete first with correct save
  13. states, such as greedy versus non-greedy repetition.
  14. For more information, see: https://swtch.com/~rsc/regexp/regexp2.html
  15. **Implementation Details:**
  16. - Each opcode is 8 bits in size, and most instructions have no operands.
  17. - All operands larger than `u8` are read in system endian order.
  18. - Jump and Split instructions operate on absolute positions in `u16` operands.
  19. - Classes such as `[0-9]` are stored in a RegEx-specific slice of structs which
  20. are then dereferenced by a `u8` index from the `Rune_Class` instructions.
  21. - Each Byte and Rune opcode have their operands stored inline after the opcode,
  22. sized `u8` and `i32` respectively.
  23. - A bitmap is used to determine which PC positions are occupied by a thread to
  24. perform merging. The bitmap is cleared with every new frame.
  25. - The VM supports two modes: ASCII and Unicode, decided by a compile-time
  26. boolean constant argument provided to `run`. The procedure differs only in
  27. string decoding. This was done for the sake of performance.
  28. - No allocations are ever freed; the VM expects an arena or temporary allocator
  29. to be used in the context preceding it.
  30. **Opcode Reference:**
  31. (0x00) Match
  32. The terminal opcode which ends a thread. This always comes at the end of
  33. the program.
  34. (0x01) Match_And_Exit
  35. A modified version of Match which stops the virtual machine entirely. It is
  36. only compiled for `No_Capture` expressions, as those expressions do not
  37. need to determine which thread may have saved the most appropriate capture
  38. groups.
  39. (0x02) Byte
  40. Consumes one byte from the text using its operand, which is also a byte.
  41. (0x03) Rune
  42. Consumes one Unicode codepoint from the text using its operand, which is
  43. four bytes long in a system-dependent endian order.
  44. (0x04) Rune_Class
  45. Consumes one character (which may be an ASCII byte or Unicode codepoint,
  46. wholly dependent on which mode the virtual machine is running in) from the
  47. text.
  48. The actual data storing what runes and ranges of runes apply to the class
  49. are stored alongside the program in the Regular_Expression structure and
  50. the operand for this opcode is a single byte which indexes into a
  51. collection of these data structures.
  52. (0x05) Rune_Class_Negated
  53. A modified version of Rune_Class that functions the same, save for how it
  54. returns the opposite of what Rune_Class matches.
  55. (0x06) Wildcard
  56. Consumes one byte or one Unicode codepoint, depending on the VM mode.
  57. (0x07) Jump
  58. Sets the Program Counter of a VM thread to the operand, which is a u16.
  59. This opcode is used to implement Alternation (coming at the end of the left
  60. choice) and Repeat_Zero (to cause the thread to loop backwards).
  61. (0x08) Split
  62. Spawns a new thread for the X operand and causes the current thread to jump
  63. to the Y operand. This opcode is used to implement Alternation, all the
  64. Repeat variations, and the Optional nodes.
  65. Splitting threads is how the virtual machine is able to execute optional
  66. control flow paths, letting it evaluate different possible ways to match
  67. text.
  68. (0x09) Save
  69. Saves the current string index to a slot on the thread dictated by the
  70. operand. These values will be used later to reconstruct capture groups.
  71. (0x0A) Assert_Start
  72. Asserts that the thread is at the beginning of a string.
  73. (0x0B) Assert_End
  74. Asserts that the thread is at the end of a string.
  75. (0x0C) Assert_Word_Boundary
  76. Asserts that the thread is on a word boundary, which can be the start or
  77. end of the text. This examines both the current rune and the next rune.
  78. (0x0D) Assert_Non_Word_Boundary
  79. A modified version of Assert_Word_Boundary that returns the opposite value.
  80. (0x0E) Multiline_Open
  81. This opcode is compiled in only when the `Multiline` flag is present, and
  82. it replaces both `^` and `$` text anchors.
  83. It asserts that either the current thread is on one of the string
  84. boundaries, or it consumes a `\n` or `\r` character.
  85. If a `\r` character is consumed, the PC will be advanced to the sibling
  86. `Multiline_Close` opcode to optionally consume a `\n` character on the next
  87. frame.
  88. (0x0F) Multiline_Close
  89. This opcode is always present after `Multiline_Open`.
  90. It handles consuming the second half of a complete newline, if necessary.
  91. For example, Windows newlines are represented by the characters `\r\n`,
  92. whereas UNIX newlines are `\n` and Macintosh newlines are `\r`.
  93. (0x10) Wait_For_Byte
  94. (0x11) Wait_For_Rune
  95. (0x12) Wait_For_Rune_Class
  96. (0x13) Wait_For_Rune_Class_Negated
  97. These opcodes are an optimization around restarting threads on failed
  98. matches when the beginning to a pattern is predictable and the Global flag
  99. is set.
  100. They will cause the VM to wait for the next rune to match before splitting,
  101. as would happen in the un-optimized version.
  102. (0x14) Match_All_And_Escape
  103. This opcode is an optimized version of `.*$` or `.+$` that causes the
  104. active thread to immediately work on escaping the program by following all
  105. Jumps out to the end.
  106. While running through the rest of the program, the thread will trigger on
  107. every Save instruction it passes to store the length of the string.
  108. This way, any time a program hits one of these `.*$` constructs, the
  109. virtual machine can exit early, vastly improving processing times.
  110. Be aware, this opcode is not compiled in if the `Multiline` flag is on, as
  111. the meaning of `$` changes with that flag.
  112. */
  113. package regex_vm