You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow specifying multiple input files to the generate_cases.py script, making it behave mostly as if the input files were concatenated. Additionally allow existing definitions of instructions to be explicitly overridden using a new override keyword.
I attach a PR with a proposed initial implementation.
Pitch
In Cinder we add a number of new instructions to support our features like Static Python. We also currently have a few tweaks to existing instructions. When we migrate to the new upstream generated interpreter it would be preferable if we could avoid having to make changes to the core bytecodes.c and keep our own definitions/changes separate. As well as easing upstream merges, this would also avoid us having to copy/fork more than we need for Cinder features in a standalone module.
I've made an initial implementation which allows extra files to be passed to generate_cases.py by repeated use of the -i argument. E.g.:
This mostly behaves as if the input files are concatenated but parsing only takes place between the BEGIN/END BYTECODES markers in each file. We also take advantage of mostly existing book-keeping features to track which input files definitions come from when producing errors.
I've also added a new override keyword which can prefix instruction definitions to explicitly express the intent to override an existing definition. E.g.:
inst(NOP, (--)) {
}
// This is the definition which ends up being used in generation.
override inst(NOP, (--)) {
magic();
}
// Error - previous definition of NOP exists and "override" not specified.
inst(NOP, (--)) {
}
// Error - requested override but no previous definition of ZOP exists.
override inst(ZOP, (--)) {
}
The goal of explicitly calling out overrides is to quickly reveal if either: something we modify is removed from upstream, or if a new opcode we add ends up with a name clash with a new upstream opcode.
Feature or enhancement
Allow specifying multiple input files to the
generate_cases.py
script, making it behave mostly as if the input files were concatenated. Additionally allow existing definitions of instructions to be explicitly overridden using a newoverride
keyword.I attach a PR with a proposed initial implementation.
Pitch
In Cinder we add a number of new instructions to support our features like Static Python. We also currently have a few tweaks to existing instructions. When we migrate to the new upstream generated interpreter it would be preferable if we could avoid having to make changes to the core
bytecodes.c
and keep our own definitions/changes separate. As well as easing upstream merges, this would also avoid us having to copy/fork more than we need for Cinder features in a standalone module.I've made an initial implementation which allows extra files to be passed to
generate_cases.py
by repeated use of the-i
argument. E.g.:This mostly behaves as if the input files are concatenated but parsing only takes place between the
BEGIN/END BYTECODES
markers in each file. We also take advantage of mostly existing book-keeping features to track which input files definitions come from when producing errors.I've also added a new
override
keyword which can prefix instruction definitions to explicitly express the intent to override an existing definition. E.g.:The goal of explicitly calling out overrides is to quickly reveal if either: something we modify is removed from upstream, or if a new opcode we add ends up with a name clash with a new upstream opcode.
Previous discussion
The idea of having multiple input files for interpreter generation was briefly discussed around the faster-cpython project.
Linked PRs
The text was updated successfully, but these errors were encountered: