On Fri, 17 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote:
> >>
> >>I don't know yet, what are the goals of this patch. There is not any
> >>sign in the list, that ops should be numbered like that and so on ...
>
> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> That's fine, basically. But there are some points, that we might
> consider:
None of the numbers (well, OK, besides end) are fixed. I threw them in the
file in alphabetic order and renumbered specifically to make sure the JIT
broke good and proper. (Any renumbering broke the JIT, so I wanted to
make sure that they didn't get overlooked) I don't much care what
order they're in the final
> * Do this change later, when we have complete opcode support - a lot
> of e.g. string ops related to PMCs are just missing now.
> There is currently no urgent need, to have fix opcode numbers - we
> don't have Parrot 1.00 (or even 0.1.0).
Missing ops aren't a big deal--any op that isn't in the list gets a number
assigned to it, so there shouldn't be anything that needs to be done for
new ops besides occasionally going through and sticking them in the ops
file.
> *If* we renumber opcodes, then lib/Parrot/OpLib/core.pm should be sorted.
> This file is the base (and holds the numbering) of all utilities using
> ops. When this file is ordered to our needs, *no* other changes (and
> code duplication) in other utils is needed. For this reason, I reverted
> your patches to ops2c and jit2 - they are just in the wrong files.
Put them *back*, please, unless you're going to fix core.pm. This is one
of those cases where, like it or not, you get to deal with what I've done.
If the numbering should go into core.pm, fine, but until core.pm
returns explicit numbers (and nothing should be counting on the
ordering from it) leave it where it is.
> We have exactly one magic opcode that is "end". The other opcodes are
> *constant*. The "noop" is considered constant for "hyterical reasons"
> and as outlined in my summary to dynamic oplibs can be used for
> optimizations (replace some code with op_func_table[CORE_OPS_noop]).
> The C<wrapper__>, C<prederef__>, and C<check_events__> opcodes are
> constant too, because they are inserted for dynamic opcodes,
> prederefencing, and for event checking (which is not rediffed yet).
There's no need for wrapper__--the proper op numbers should be inserted
when the code is generated. I'll go dig, but I don't understand the reason
for prederef__ since anything the deref core needs should be done at
runtime. check_events__ is just another op and, once again, should just
get thrown in as need be.
Dan
