About the opcodes of Perl

PerlOnTheWay has asked for the wisdom of the Perl Monks concerning the following question:

As we know perl's executor does a simple job:

int
Perl_runops_standard(pTHX)
{
    dVAR;
    register OP *op = PL_op;
    while ((PL_op = op = op->op_ppaddr(aTHX))) {
    }

    TAINT_NOT;
    return 0;
}
[download]

So that means each opcode is chained,it will return the next opcode when return.

PP(pp_cond_expr)
{
    dVAR; dSP;
    PERL_ASYNC_CHECK();
    if (SvTRUEx(POPs))
    RETURNOP(cLOGOP->op_other);
    else
    RETURNOP(cLOGOP->op_next);
}
[download]

The above matches what I assume.

But I still see many of them not matching:

PP(pp_unstack)
{
    dVAR;
    PERL_ASYNC_CHECK();
    TAINT_NOT;        /* Each statement is presumed innocent */
    PL_stack_sp = PL_stack_base + cxstack[cxstack_ix].blk_oldsp;
    FREETMPS;
    if (!(PL_op->op_flags & OPf_SPECIAL)) {
    I32 oldsave = PL_scopestack[PL_scopestack_ix - 1];
    LEAVE_SCOPE(oldsave);
    }
    return NORMAL;
}
[download]

The above doesn't return cLOGOP->op_next,how can the executor still chain them together?

Comment on About the opcodes of Perl Select or Download Code

Replies are listed 'Best First'.
Re: About the opcodes of Perl by Anonymous Monk on Sep 02, 2011 at 09:24 UTC
how can the executor still chain them together? Magic :) But seriously, where do you see cLOGOP->op_next in PP(pp_unstack)? Do you what what is NORMAL? Unraveling the execution path sounds like a job for a debugger :)	[reply]
Re^2: About the opcodes of Perl by PerlOnTheWay (Monk) on Sep 02, 2011 at 09:39 UTC
Hah,I missed that... I also found that `RETURN` alone does something similar: `#define RETURN return (PUTBACK, NORMAL)` [download] Why perl uses so many different ways to do the same thing? The version I download is 5.14.1,which may not be the newest.	[reply] [d/l] [select]
Re^3: About the opcodes of Perl by ikegami (Patriarch) on Sep 02, 2011 at 09:59 UTC
huh, none of `RETURNOP(cLOGOP->op_other); RETURNOP(cLOGOP->op_next); RETURN; return NORMAL;` [download] don't do the same thing. The fourth could probably use a more consistent name, but they other three are rather consistent. I don't see the complain.	[reply] [d/l]
Re^3: About the opcodes of Perl by Anonymous Monk on Sep 02, 2011 at 09:50 UTC
Why perl uses so many different ways to do the same thing? :) 1) I don't know that it does 2) p5p might know 3) code evolves 4) different strokes 5) similar is not same, they're different 6) olly olly oxen free	[reply]
Re: About the opcodes of Perl by locked_user sundialsvc4 (Abbot) on Sep 02, 2011 at 14:38 UTC
I know that, when I write interpreters, the opcodes are very often highly specific. Especially, say, in the ops that handle loop-structures. Although in a traditional compiler you might generate large numbers of very-simple opcodes (extremely so, in the case of RISC), a p-code interpreter (IMHO) favors fewer numbers of iterations through the main fetch-and-execute loop, thus complex opcodes. There’s really no incremental cost in adding another one. Perl, AFAIK, always compiles on-the-fly (as opposed to Python’s `.pyc` files, e.g.), so the concern of bytecode backwards-compatibility in existing p-code files is not a concern. But for others, including some that I have written, it is. When you find a better way to do things, you have to keep support for the old way so that older programs continue to run. (In my case, I actually had to re-define the p-code record format ... oh well.)