We still have a lot of unhooked ops w/o a definite opcode number. These are mainly the non-branching compare opcodes currently located in ops/experimental.ops.
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.
They're useful in larger programs -- they significantly cut down on the number of branches and labels in languages that define comparisons to return a 0 or 1, and that cuts down on compilation time significantly.
So first: - do we keep these opcodes?
Yes.
If yes some permutations are missing.
Yeah. I'd as soon leave them out until we need them.
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.
These can move into the standard library. Rand's probably a good candidate for a PMC, but that's a separate thing.
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"(...)
Time to talk about namespaces and stake out the ones we want. I'll do that in the next message so we can keep the threads separate.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
