Minor nit: these were alphabetized before, and now they're not. I think it makes sense to reorder the implementations below, but I'm not sure there's also value in reordering these.

I'm not a big fan of alphabetization any more (just search :-), and I tried to let the grouping match the ordering of the definitions below, with the exception of BINARY_OP itself, which is somewhere else entirely.

TBH I'm not sure that there's a single organizing principle in the ordering in this file any more; I like to keep families together, but I also don't like to move code around unnecessarily.

If you insist I can undo this chunk.

Also, I think maybe the name could just be _GUARD_INT or something, since this could potentially be reused for things like COMPARE_OP.

We could rename it once we get to that bridge... But we'd probably end up moving it around again too. Anyway, it looks like there are other concerns for these guards.

Suggested name GUARD_BOTH_INTS as it checks that both are ints, regardless of how they are used.

I'll use _GUARD_BOTH_INT, _GUARD_BOTH_FLOAT, and _GUARD_BOTH_UNICODE.

It seems to me that there might be value in splitting these types of checks up: one for guarding the top of stack, and one for guarding the second item on the stack.

That way we could successfully remove uops for cases like 1 + rhs or lhs += 1, where they type of one argument is known (or inferred).

Just a heads up: in the very near future for py lazy basic block, we plan to just have a generic CHECK_INT x that checks the xth stack entry is indeed an int. The main reason is that it would save us an opcode.

That makes sense. Just need space for a couple extra opargs. I wonder if it would make sense to have "hardcoded" or "shared" opargs as part of macro instructions.

So we could have (with straw-man syntax):

macro(BINARY_OP, oparg) = _BINARY_OP_SPECIALIZE(oparg) + _BINARY_OP_ACTION(oparg);
macro(BINARY_OP_ADD_INT, oparg) = _CHECK_INT(1) + _CHECK_INT(2) + _BINARY_OP_ADD_INT(oparg);

I sort of like it, and maybe the scheme could be extended to share other locals or caches too.

@gvanrossum, thoughts on something like the above?

I forgot to also mention that we encountered many situations where one type is known but the other isnt. So it helps to have some granularity.

These are all very interesting proposals, and I'll hold up this PR until we've got some agreement on what we eventually want to do.

• Splitting the type-checking guard into atomic pieces: this makes sense from the POV of machine code generation (fewer, simpler templates) but it would make the Tier-2 interpreter slower, due to increased opcode decoding overhead (unless the guards can be eliminated, of course). There are various possible ways to address that though (possibly even super-micro-ops :-), so maybe we should just go for it, if we can agree on a syntax.
• Having micro-ops with parameters, notably _CHECK_INT(1). I don't know how much effort this would be in the generator, but I expect it'll be easy enough, and if we are indeed going with the smallest possible uops, we should just do it.
• Being explicit about which uops use oparg. This feels like it might require more effort in the generator, but it also sounds like an interesting way to go.

All in all, I think we should probably have an in-person discussion about this (earliest I'm available is the week of June 5th).

I'd keep the checks for pairs of values for now.
Even if we want to separate them for optimization, we are likely to want to combine them into superinstructions for interpretation, so we might as well keep them for now.

We can always split them up later.

Okay, I think I'll follow Mark's guidance, and keep the current structure.

This might benefit in the future from being two additional uops too, since they can be removed for known immortal values (although mechanically that might be difficult right now, given that we don't have a good way of sharing locals across uops).

Yeah, once we're over our concern for dispatch overhead in the Tier-2 interpreter, that makes a lot of sense. But I'm not quite over that (I still would like to see a Tier-2 interpreter that not slower than Tier-1 without all conceivable optimizations). So maybe we should just postpone this (maybe we need a new Ideas issue about the granularity of uops).

Let's not worry about refcount stuff for now, we can always do it later.
The important thing for now is that the interpreter generator can understand instructions made up of a sequence of micro-ops. With that we can break down instructions as much as we like later on.

This should be left alone.
We don't need or want to break up all instructions, just the specialized ones.
In fact, next_instr will not available to the tier 2 optimizer, so it will have to reject this instruction.

Good point. In tier 2 we have to set ENABLE_SPECIALIZATION to false, since specializing a tier 2 instruction makes no sense -- that's the job of tier 1.