Skip to content

Introducing macro in the interpreter definition DSL #491

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gvanrossum opened this issue Nov 8, 2022 · 0 comments
Closed

Introducing macro in the interpreter definition DSL #491

gvanrossum opened this issue Nov 8, 2022 · 0 comments
Labels
epic-generator DSL-based code generator for the interpreter(s)

Comments

@gvanrossum
Copy link
Collaborator

The interpreter definition DSL currently has these two syntactic forms:

  definition:
    kind "(" NAME "," stack_effect ")" "{" C-code "}"
    |
    kind "(" NAME ")" "=" uop ("+" uop)* ";"

However, these two forms are incompatible with each other if we want to pretend that Python/bytecodes.c is a C file -- we can't define a dummy inst() macro that can be used in both contexts.

I propose to use different keywords for different syntax, in particular:

  definition:
    "inst" "(" NAME ("," stack_effect)? ")" "{" C-code "}"
    |
    "op" "(" NAME "," stack_effect ")" "{" C-code "}"
    |
    "macro" "(" NAME ")" "=" uop ("+" uop)* ";"
    |
    "super" "(" NAME ")" "=" NAME ("+" NAME)* ";"

Thus, inst and op always have a block of C code; macro and super always combine other instructions or opcodes. (An uop is an op name or a cache effect.)

(An inst without stack effect is a legacy instruction.)

The difference between super and macro is in how they are dispatched: a super-instruction has 2 or more opargs and is encoded as 2 or more code units (and moreover, jumping to the second of these will execute the second half of the super-instruction). A macro instruction has a single oparg and takes up a single code unit (not counting inline cache fields). Only macro can also take cache effects as input.

I also propose that inst, macro and super always define top-level bytecode instructions. (It is already the case that op always defines a building block.) super can only combine top-level bytecode instructions; macro can only combine ops and stack effects. I doubt we'll need macros as input to other macros.

PS: If and when we switch to a register machine these things will have to change anyway.

gvanrossum added a commit that referenced this issue Nov 8, 2022
markshannon pushed a commit that referenced this issue Nov 14, 2022
@gvanrossum gvanrossum added the epic-generator DSL-based code generator for the interpreter(s) label Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic-generator DSL-based code generator for the interpreter(s)
Projects
None yet
Development

No branches or pull requests

1 participant