bpo-47120: define virtual opcodes in opcode.py. Better organization of jump opcodes.

[iritkatriel]

https://bugs.python.org/issue47120

[markshannon]

I'm not keen on this change.
It exposes a lot of highly changeable, internal details.

The "virtual" instructions don't exist outside of the compiler, so why expose them?
And why renumber all the jumps?

[markshannon]

Aren't we about to remove all absolute jumps?

[iritkatriel]

Yes, and then this flag will not be needed.

[markshannon]

These are an internal detail of the compiler. They never exist in the final bytecode, so I don't think they should be here.

[iritkatriel]

The point was to autogenerate some of the macros around them.

[markshannon]

If the code to generate the macro is large than macros, that suggests to me that it isn't worth it.

[iritkatriel]

For me it's not about how long the code is, but about how many places we need to change when we add/remove/change an opcode (i.e., maintainability).

[iritkatriel]

And why renumber all the jumps?

We will need to do that if we want to use the evenness of a jump opcode to determine its direction (I'm not entirely sure we want to do that though).

[iritkatriel]

I'll make the jumps change with the current scheme and we can refactor afterwards when the mess is more obvious.

[markshannon]

Ultimately I expect that we will want all opcodes to be auto-generated from profiling information, to reduce the effective size of the dispatch table.