Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Fri, 17 Oct 2003, Leopold Toetsch wrote:
>> *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. I'll reorder core.pm (generation). Then jit2h (and other utils) aren't broken. This puts the renumbering in one place. Your approach was just wrong IMHO. > 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. core.pm is generated by ops2pm and is used by all utilities that deal with opcode libraries. So generating core.pm with the fixed numbering of ops.num seems to be by far the simplest approach and doesn't break all possible run cores. >> We have exactly one magic opcode that is "end". The other opcodes are >> *constant*. > There's no need for wrapper__--the proper op numbers should be inserted > when the code is generated. When you run some code e.g. with the CGP core and you load an oplib, that doesn't have a CGP flavor - only functions, then the wrapper__ opcode inside the CGP core calls the dynamic opcode function of the dynamic oplib. Or when running -j: JIT emits a call to the wrapper__ op, that then executes the real function. The wrapper__ op might go away *if* we demand, that all oplibs are generated in all run core flavors, and *if* the oplib PMC is in the metadata, which depends on the freeze/thaw interface. For now the wrapper__ is needed and has to be a constant (well known) number. > ... I'll go dig, but I don't understand the reason > for prederef__ since anything the deref core needs should be done at > runtime. The prederefed copy of the bytecode is filled with the prederef__ opcode. When executed, it calls do_prederef, which fills in the real function/opcode label/opcode number. Before this change, predereferncing was done in advance for CGP and switch core. This isn't possible any more because of dynamic oplibs. Predereferencing most be done just in time. > ... check_events__ is just another op and, once again, should just > get thrown in as need be. All these are plain ops, nothing special, except that their number is defined in oplib.h. If ops renumbering patches/generates this enum with matching opcode numbers all will continue to work. But as outlined for debugging its just simpler, to have some small numbers then 1227, so I'd prefer to have these ops (0-8) just in that order. > Dan leo
