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: * sort op numbers by usage, so that we have better code locality * sort ops by category. This could be useful to disable one block of ops (e.g. IO) for the safe core * leave them as they are *but* consider the numbers fixed - we add new ops only to one opsfile (e.g. new.ops), that get appended to core.pm, so that all other op numbers are fixed. * 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). *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. >>Second, you for sure did ignore all comments in core.ops and my >>summaries, how various things are *working* now. > No, I didn't. All I did was run through the generated output and > strip out values, making sure that end was 0. There really shouldn't > be any other magic numbers for opcodes, though I see there are some. > I can understand the noop code, though I don't see much reason to > make it a magic number. The rest I'm not seeing any need for magic > numbers--certainly not for the event checking ops, nor for the > wrapper op. 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). I don't care, what opcode numbers these have, they are defined in an enum in oplib.h - but for debugging its by far simpler to seen an opcode number 6 (prederef__) then to have 1227. > If they're needed now, then this is the time to make them not needed.. They are needed and will be needed and they are constant - not magic. >>This patch breaks all predereferenced cores as well as dynamic opcode >>libraries at first sight. > And the JIT, yes. (Though I was unaware the prederef cores broke) > That's fine. Fixing them is simple enough to do. Yes, s. above, generate core.pm in the desired order. leo
