Dan Sugalski <[EMAIL PROTECTED]> wrote:Folks,
I've added in the infrastructure needed to implement fixed opcode numbers. There's now a file ops.num that holds the opcode name/number pairs for all ops with a fixed number.
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.
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.
If they're needed now, then this is the time to make them not needed..
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.
If you don't have really *very* strong arguments for this patch then please just undo it - now - thanks.
I do. It needs doing, and it needs doing now, before we make more changes to the runloops, to make sure things aren't more difficult to fix later. If it's just a matter of changing a few op numbers in the ops.num file, then that's fine--this is the time to change them.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
