Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions InternalDocs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,13 +11,16 @@ The core dev team attempts to keep this documentation up to date. If
it is not, please report that through the
[issue tracker](https://github.com/python/cpython/issues).

List of topics:

[Guide to the parser](parser.md)

[Compiler Design](compiler.md)

[Frames](frames.md)

[Bytecode Interpreter](bytecode_interpreter.md)

[Adaptive Instruction Families](adaptive.md)

[The Source Code Locations Table](locations.md)
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -32,8 +32,7 @@ The presence of these macros and the nature of bytecode interpreters means
that the interpreter is effectively defined in a domain specific language (DSL).

Rather than using an ad-hoc DSL embedded in the C code for the interpreter,
a custom DSL should be defined and the semantics of the bytecode instructions,
and the instructions defined in that DSL.
a custom DSL is defined. This DSL defines the semantics of the bytecode instructions.

Generating the interpreter decouples low-level details of dispatching
and error handling from the semantics of the instructions, resulting
Expand All @@ -53,11 +52,10 @@ to be written. One way to mitigate this is through the use of code generators.
Code generators decouple the debugging of the code (the generator) from checking
the correctness (the DSL input).

For example, we are likely to want a new interpreter for the tier 2 optimizer
to be added in 3.12. That interpreter will have a different API, a different
set of instructions and potentially different dispatching mechanism.
But the instructions it will interpret will be built from the same building
blocks as the instructions for the tier 1 (PEP 659) interpreter.
New interpreter for the tier 2 optimizer is added in CPython 3.13.
That interpreter have a different API, a different set of instructions and
different dispatching mechanism. But the instructions it interpret are built
from the same building blocks as the instructions for the tier 1 (PEP 659) interpreter.

Rewriting all the instructions is tedious and error-prone, and changing the
instructions is a maintenance headache as both versions need to be kept in sync.
Expand All @@ -74,7 +72,7 @@ We update it as the need arises.
### Syntax

Each op definition has a kind, a name, a stack and instruction stream effect,
and a piece of C code describing its semantics::
and a piece of C code describing its semantics:

```
file:
Expand Down Expand Up @@ -245,7 +243,8 @@ The same is true for all members of a pseudo instruction

## Examples

(Another source of examples can be found in the [tests](test_generator.py).)
(Another source of examples can be found in the
[tests](https://github.com/python/cpython/blob/main/Lib/test/test_generated_cases.py).)

Some examples:

Expand Down
2 changes: 1 addition & 1 deletion Tools/cases_generator/README.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# Tooling to generate interpreters

Documentation for the instruction definitions in `Python/bytecodes.c`
("the DSL") is [here](interpreter_definition.md).
("the DSL") is [here](https://github.com/python/cpython/blob/main/InternalDocs/bytecode_interpreter.md).

What's currently here:

Expand Down
Loading