GeezerVison

This is not yet working for pseudo instructions. Should we add them to bytecodes.c in some form?

I think so (unless all the flags are always false for all pseudo-ops, which I doubt is the case). In fact I think we should probably propose a solution for moving the canonical definition of the numeric opcode values before we move on this.

(Other than that, this approach seems fine.)

Also I don’t know how to identify the jump opcodes in the generator. JUMPBY is used for caches so it’s no help. Maybe we could have a SKIP_CACHE macro and the a jumpby is really a jump?

LG. Next steps?

LG. Next steps?

next is to rebase and enable the assertions for pseudo ops. If that worksI'll check the diff, maybe this PR is done then.

Maybe we should make the parser or generator complain if you use frame->f_code->co_names or frame->f_code->co_consts in a bytecode definition?

Maybe we should make the parser or generator complain if you use frame->f_code->co_names or frame->f_code->co_consts in a bytecode definition?

How would it know? Maybe the original idea of looking for that sequence of tokens isn't so bad. Just don't fold it into variable_used -- make it a separate helper function.

Maybe we should make the parser or generator complain if you use frame->f_code->co_names or frame->f_code->co_consts in a bytecode definition?

How would it know? Maybe the original idea of looking for that sequence of tokens isn't so bad. Just don't fold it into variable_used -- make it a separate helper function.

I didn't like that frame->f_code->co_names means something different then code = frame->f_code; code->co_names.
We could make it illegal to access frame->f_code from the code, and add #defines for everything you might need from there.

I grepped and I see about a dozen places where frame->f_code is used to access something other than co_consts or co_names. So you'd need to review those.