TODOish fix ops
Leopold Toetsch
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.
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
Jens Rieks
> 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.
Has anyone else except Leo and Dan used 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.
> 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 :)
Sounds like a task for me. I'll have a look at it.
> leo
Steve Fink
> Leopold Toetsch wrote:
> > So first:
> > - do we keep these opcodes?
> > If yes some permutations are missing.
> > opcode set or move it to dynops.
> I have not used them yet, but I think that they can be useful.
> Has anyone else except Leo and Dan used them?
I use them for debugging printouts, when I want to print the status of
something without defining a bunch of labels and contorting the control
flow. I also use them for simple non-short-circuiting ors and ands.
Nothing terribly important or irreplaceable.
Dan Sugalski
>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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 6:55 PM +0200 9/2/04, Leopold Toetsch wrote:
>>- do we keep these opcodes?
> Yes.
Ok.
>> If yes some permutations are missing.
> Yeah. I'd as soon leave them out until we need them.
Well, the asymmetry makes it harder for compilers to emit proper code.
"Is that variant already implemented". So I'd rather have it complete.
> These can move into the standard library. Rand's probably a good
> candidate for a PMC, but that's a separate thing.
It *is* a PMC. The opcodes got added later.
leo