in reply to [XS] Manipulating the Stack

I don't know the semantics of PL_markstack_ptr, but I would guess that it's an internal detail that might be subject to change in the future. If it does, I'd be happy to let the Inline::C maintainers deal with that and not have to re-release all my Inline-derived modules. While the XS you point at might look awkward, that only comes out to about 4 processor instructions more than your improved version, so I doubt there is any performance difference.

If you think there is a reliable way to avoid that dance, maybe contribute a patch to Inline::C instead? I mean, Inline can look at the C source code and try parsing it to find out if it is actually pushing things onto the stack.... maybe.

Replies are listed 'Best First'.
Re^2: [XS] Manipulating the Stack
by syphilis (Archbishop) on Oct 17, 2023 at 05:37 UTC
    I don't know the semantics of PL_markstack_ptr, but I would guess that it's an internal detail that might be subject to change in the future.

    It's documented in perlguts, though reading that documentation has not helped me any.
    I think that makes it public - at least public enough that any alteration to its usage will be outlined in perlguts. And it has been in Inline::C and Inline::CPP for a very long time, without ever causing problems.

    For me, it's more about removing arcane clutter that is deployed only by Inline::C/CPP, rather than looking for improved running performance.
    Many of the "truly void" functions (eg those that don't invoke dXSARGS) don't even need to increment the ptr - so, for them: 
    void
foo (x)
    SV *    x
        PREINIT:
        I32* temp;
        PPCODE:
        temp = PL_markstack_ptr++;
        foo(x);
        if (PL_markstack_ptr != temp) {
          /* truly void, because dXSARGS not invoked */
          PL_markstack_ptr = temp;
          XSRETURN_EMPTY; /* return empty stack */
        }
        /* must have used dXSARGS; list context implied */
        return; /* assume stack size is correct */

    [download]
    can be rewritten as: 
    void
foo (x)
    SV *    x
        CODE:
        foo(x);
        XSRETURN_EMPTY;

    [download]
    which is much more readily comprehensible, and much more concise.

    See https://github.com/Perl/perl5/issues/21523 where the issue was first reported. And also see https://github.com/ingydotnet/inline-c-pm/issues/104 for a bit of a discussion, and for Tony Cook's solution that suppresses the warnings shown in the former link.
    I've actually started using a hacked Inline::C that eliminates the need for relying on "the PL_markstack_ptr dance". (It's based on the idea mentioned in that bug report - though it required some additional refining not mentioned there ... and it's probably not everyone's preferred approach.)

    Cheers,
    Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom