gh-119786: Edit InternalDocs/frames.md, Python/vm-state.md, Python/tier2_engine.md

InternalDocs/README.md

@@ -21,3 +21,5 @@ it is not, please report that through the
 [The Source Code Locations Table](locations.md)
 
 [Exception Handling](exception_handling.md)
+
+[The Virtual Machine](vm-state.md)

Python/vm-state.md → InternalDocs/vm-state.md

@@ -3,24 +3,25 @@
 ## Definition of Tiers
 
 - **Tier 1** is the classic Python bytecode interpreter.
-  This includes the specializing adaptive interpreter described in [PEP 659](https://peps.python.org/pep-0659/) and introduced in Python 3.11.
+  This includes the specializing [adaptive interpreter](adaptive.md).
 - **Tier 2**, also known as the micro-instruction ("uop") interpreter, is a new interpreter with a different instruction format.
-  It will be introduced in Python 3.13, and also forms the basis for a JIT using copy-and-patch technology that is likely to be introduced at the same time (but, unlike the Tier 2 interpreter, hasn't landed in the main branch yet).
+  It was introduced in Python 3.13, and also forms the basis for a JIT using copy-and-patch technology. See [Tier 2](tier2_engine.md) for more information.
+
 
 # Frame state
 
 Almost all interpreter state is nominally stored in the frame structure.
-A pointer to the current frame is held in `frame`. It contains:
+A pointer to the current frame is held in `frame`, for more information about what `frame` contains see [Frames](frames.md):
+
+# Thread state and interpreter state
 
-- **local variables** (a.k.a. "fast locals")
-- **evaluation stack** (tacked onto the end of the locals)
-- **stack top** (an integer giving the top of the evaluation stack)
-- **instruction pointer**
-- **code object**, which holds things like the array of instructions, lists of constants and names referenced by certain instructions, the exception handling table, and the table that translates instruction offsets to line numbers
-- **return offset**, only relevant during calls, telling the interpreter where to return
+Another important piece of VM state is the **thread state**, held in `tstate`.
+The current frame pointer, `frame`, is always equal to `tstate->current_frame`.
+The thread state also holds the exception state (`tstate->exc_info`) and the recursion counters (`tstate->c_recursion_remaining` and `tstate->py_recursion_remaining`).
 
-There are some other fields in the frame structure of less importance; notably frames are linked together in a singly-linked list via the `previous` pointer, pointing from callee to caller.
-The frame also holds a pointer to the current function, globals, builtins, and the locals converted to dict (used to support the `locals()` built-in).
+The thread state is also used to access the **interpreter state** (`tstate->interp`), which is important since the "eval breaker" flags are stored there (`tstate->interp->ceval.eval_breaker`, an "atomic" variable), as well as the "PEP 523 function" (`tstate->interp->eval_frame`).
+The interpreter state also holds the optimizer state (`optimizer` and some counters).
+Note that the eval breaker may be moved to the thread state soon as part of the multicore (PEP 703) work.
 
 ## Fast locals and evaluation stack
 
@@ -47,7 +48,7 @@ The Tier 2 instruction pointer is strictly internal to the Tier 2 interpreter, s
 
 ## Unwinding
 
-Unwinding uses exception tables to find the next point at which normal execution can occur, or fail if there are no exception handlers.
+Unwinding uses exception tables to find the next point at which normal execution can occur, or fail if there are no exception handlers. For more information on what exception tables are, see [exception handling](exception_handling.md).
 During unwinding both the stack and the instruction pointer should be in their canonical, in-memory representation.
 
 ## Jumps in bytecode
@@ -68,23 +69,3 @@ Patching exits should be fairly straightforward in the interpreter.
 It will be more complex in the JIT.
 
 (We might also consider deoptimizations as a separate jump type.)
-
-# Thread state and interpreter state
-
-Another important piece of VM state is the **thread state**, held in `tstate`.
-The current frame pointer, `frame`, is always equal to `tstate->current_frame`.
-The thread state also holds the exception state (`tstate->exc_info`) and the recursion counters (`tstate->c_recursion_remaining` and `tstate->py_recursion_remaining`).
-
-The thread state is also used to access the **interpreter state** (`tstate->interp`), which is important since the "eval breaker" flags are stored there (`tstate->interp->ceval.eval_breaker`, an "atomic" variable), as well as the "PEP 523 function" (`tstate->interp->eval_frame`).
-The interpreter state also holds the optimizer state (`optimizer` and some counters).
-Note that the eval breaker may be moved to the thread state soon as part of the multicore (PEP 703) work.
-
-# Tier 2 IR format
-
-The tier 2 IR (Internal Representation) format is also the basis for the Tier 2 interpreter (though the two formats may eventually differ). This format is also used as the input to the machine code generator (the JIT compiler).
-
-Tier 2 IR entries are all the same size; there is no equivalent to `EXTENDED_ARG` or trailing inline cache entries. Each instruction is a struct with the following fields (all integers of varying sizes):
-
-- **opcode**: Sometimes the same as a Tier 1 opcode, sometimes a separate micro opcode. Tier 2 opcodes are 9 bits (as opposed to Tier 1 opcodes, which fit in 8 bits). By convention, Tier 2 opcode names start with `_`.
-- **oparg**: The argument. Usually the same as the Tier 1 oparg after expansion of `EXTENDED_ARG` prefixes. Up to 32 bits.
-- **operand**: An additional argument, Typically the value of *one* cache item from the Tier 1 inline cache, up to 64 bits.