These opcodes have some limited usefullness for e.g.
bool_val = (a < b) && (c > d)
i.e. for expressions that do not branch on the compare result. If a branch is done, the AST or whatever optimizer always can convert such sequences to our branching compare opcodes.
I've found very little usage of these opcodes during translating Python bytecode or AST, albeit some code looks better with these opcodes and I have used these ops.
So first:
- do we keep these opcodes?
If yes some permutations are missing.
- if no,´ we should either not include experimental.ops in the default opcode set or move it to dynops.
For the rest of the opcodes in that file (gcd, rand) I don't think, that these should be opcodes. Both gcd and rand are e.g. supported in the GMP library too. The limited range of the existing opcodes and missing PMC variants precludes better implementations. Going with PMCs and vtables too seems like overkill to me.
I think, we need to make such functionality available as library functions. Please also remember that each opcode gets multiplicated into every runcore we have, with the whole function body duplicated.
I'm thinking of putting these functions into e.g. ext/math.c and make it available as:
math = get_namespace ["math"] gcd = math."gcd"(...)
that is a NCI call with a given namespace (which should of course be available and organized a bit :)
leo
