Branch: refs/heads/davem/xs_refactor9
Home: https://github.com/Perl/perl5
Commit: 2fd3cd18765c519b975cdbcdcea63295dd897bf7
https://github.com/Perl/perl5/commit/2fd3cd18765c519b975cdbcdcea63295dd897bf7
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Constants.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/CountLines.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Eval.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Node.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/Cmd.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/InputMap.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/Type.pm
M dist/ExtUtils-ParseXS/lib/perlxs.pod
Log Message:
-----------
ParseXS: bump version 3.56 => 3.57
Commit: 765495bb14a034d9d6649f849e93f12ef7419b90
https://github.com/Perl/perl5/commit/765495bb14a034d9d6649f849e93f12ef7419b90
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: add tests for special array(type,n) type
There is currently only a single test for the special-cased return
type "array(type,nitems)" - which returns a packed string containing
nitems of type, on the assumption that RETVAL has been assigned a
pointer to an array of type[nitems].
So this commit adds more comprehensive tests.
Commit: 31e7e327954633849168ce9eb0dc50401485140c
https://github.com/Perl/perl5/commit/31e7e327954633849168ce9eb0dc50401485140c
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: add tests for T_ARRAY/DO_ARRAY_ELEM
The T_ARRAY typemap input and output code relies on a special token,
DO_ARRAY_ELEM, which is converted by ParseXS into code to get/set
each element of an array.
This commit adds several tests for this under-tested misfeature.
A few of the tests are marked with 'XXX' comments where I explain that
they test the *current* behaviour, not necessarily the correct or best
behaviour.
Commit: 588105dd889d7b6633430ba7490bbc4db0c5b76f
https://github.com/Perl/perl5/commit/588105dd889d7b6633430ba7490bbc4db0c5b76f
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Node.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: fix DO_ARRAY_ELEM boundaries
Both INPUT and OUTPUT typemap template processing expand the text
token 'DO_ARRAY_ELEM'.
In particular, input processing has code like:
if ($expr =~ /DO_ARRAY_ELEM/) {
...
$expr =~ s/DO_ARRAY_ELEM/$subexpr/;
}
and output processing has code like:
if ($expr =~ /DO_ARRAY_ELEM/) {
...
$expr =~ s/DO_ARRAY_ELEM\n/$subexpr/;
}
Note that there is a \n in the pattern only in the second substitution.
This commit does two things. First it removes the extraneous \n, which
one assumes was a mistake; and secondly it wraps all four patterns with
\b so the token only matches as a whole word. This is very unlikely to
make any difference in the real world, as DO_ARRAY_ELEM is an
undocumented hack used only in the T_ARRAY typemap entry supplied with
perl, and not anywhere on CPAN AFAICT.
In a slight quirk, perl's INPUT and OUTPUT lines for T_ARRAY which
contain DO_ARRAY_ELEM are, respectively:
DO_ARRAY_ELEM;
DO_ARRAY_ELEM
The latter of which would now match (but wouldn't before) even if it had
a trailing ';'.
This commit also does a minor fixup to a test I added in the previous
commit, which had to temporarily not have any characters after the
DO_ARRAY_ELEM in the typemap due to the \n.
Commit: c70bfc4bacefa0d79f687847775f83de327c10e1
https://github.com/Perl/perl5/commit/c70bfc4bacefa0d79f687847775f83de327c10e1
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: forbid DO_ARRAY_ELEM on OUT,OUTLIST param
DO_ARRAY_ELEM is a text token which can appear in typemap INPUT and
OUTPUT code templates. It expands into code which sets the value of one
SV. It is intended for use within the T_ARRAY typemap, which for OUTPUT
includes DO_ARRAY_ELEM within a loop which stores new mortal SVs at
stack locations ST(0)..ST(n-1) and sets each SV to the value of each
element of RETVAL.
This makes no sense when applied to an OUT or OUTLIST parameter (as
opposed to RETVAL). The code gets emitted, but just interferes with the
code to return RETVAL. For example, in something like
int
foo(OUTLIST intARRAY* x)
code will be emitted to store temp SVs at ST(0), ST(1), ... containing
the values of x[0], x[1], ...; then code will also be emitted to store
the value of RETVAL at ST(0).
For OUT params it makes even less sense: an OUT param should update one
of the SVs passed as an argument, and shouldn't be pushing *anything*
onto the stack.
This commit makes it a compile error for the token 'DO_ARRAY_ELEM' to
appear in an OUTPUT typemap for a use other than returning RETVAL.
Commit: 2a10009adf2c284c6c1ea1e0ff0cd7f40c74afc8
https://github.com/Perl/perl5/commit/2a10009adf2c284c6c1ea1e0ff0cd7f40c74afc8
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: forbid array(t,n) on OUT,OUTLIST param
The special type 'array(some_type.nitems) is intended for use only
as the return type of an XSUB. Make using it to return other variables
an error.
Previously it was allowed, but generated broken C code.
Commit: 76e1f76a6a05d6ff4dd13bb140fd54fdf5ed1da6
https://github.com/Perl/perl5/commit/76e1f76a6a05d6ff4dd13bb140fd54fdf5ed1da6
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: handle undefined arg number in output
Add an "internal error" croak if generate_output() tries to update the
value of a passed argument whose arg num is undefined. This should
never happen. Previously there was an oblique check for this, with
the function silently returning if detected. This commit makes it more
obvious what's (not) going on.
There are no tests added because - ahem - this should ever happen.
Commit: 32b999a8aabc6df4182ed2c5161ab9bc4e5441b5
https://github.com/Perl/perl5/commit/32b999a8aabc6df4182ed2c5161ab9bc4e5441b5
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: make DO_ARRAY_ELEM separate
The last statement in generate_output() is a big four-limb if/else to
handle the main types of variable value return. This commit splits the
first branch, if ($expr =~ /\bDO_ARRAY_ELEM\b/), into a separate if(),
with an added 'return' but no else; leaving the main if/else as only
three limb.
This is a step towards making the DO_ARRAY_ELEM processing just part of
typemap processing.
Should be no change in functionality.
Commit: a7a4bbdf85f4729a19d99a617c879990287fb260
https://github.com/Perl/perl5/commit/a7a4bbdf85f4729a19d99a617c879990287fb260
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: ignore DO_ARRAY_ELEM on custom OUTPUT
When there's custom return code specified on an OUTPUT line,
use that rather than the code from the typemap OUTPUT entry: even if
that template code includes the DO_ARRAY_ELEM special token.
Commit: 0c26e100ca89219d7d149590ee6a7762a2746ed3
https://github.com/Perl/perl5/commit/0c26e100ca89219d7d149590ee6a7762a2746ed3
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: calc ST(n) once in output
In generate_output(), rather than setting $arg to "ST(n)" and later
amending it for OUTLIST parameters, just set it to the right value
initially. Should make no functional change, but just simplifies things
slightly.
Commit: 004017a4a74cdcea57f3b93a7fb19fcce6a95928
https://github.com/Perl/perl5/commit/004017a4a74cdcea57f3b93a7fb19fcce6a95928
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: honour OUTPUT override in array(type,n)
This restores the original behaviour broken during recent refactoring,
and adds tests.
In something like
array(int,5)
foo()
OUTPUT:
RETVAL my_setintptr(ST(0), RETVAL);
the special processing of the array(...) return type should be ignored
and instead the override code specified on the OUTPUT line should be
used.
This commit includes some duplicate cut and pasted perl code to return
the override; this will be refactored away shortly.
Commit: 60eb73d0a8910d2652b6065ffe256902c8e87577
https://github.com/Perl/perl5/commit/60eb73d0a8910d2652b6065ffe256902c8e87577
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: add test for OUTPUT with code + bad type
Currently when an OUTPUT line includes a code override, the type
is still looked in the typemap (even though the result won't be used).
If the type of RETVAL is unknown, this causes an error.
This commit adds a test for this error, mainly so that the next commit,
which fixes this issue, can be seen to fix the test.
Commit: dda25a91783138798712f1a1474ac6d8283fd8a7
https://github.com/Perl/perl5/commit/dda25a91783138798712f1a1474ac6d8283fd8a7
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: skip typemap lookup on OUTPUT override
Reorganise the typemap lookup code so that it's only called when
there isn't a return typemap override. For example:
blah
foo()
OUTPUT:
RETVAL some_override_code(...)
Formerly it looked up 'blah' to get an OUTPUT typemap even though it's
value wouldn't be used and the text 'some_override_code(...)' would be
used instead. This would cause an error if 'blah' couldn't be found in
the typemap.
The diff looks quite complex mainly because the ordering of some lexical
variables has been changed: all the $type-derived vars are now grouped
together, and the 'my' declarations of some vars have been moved earlier
so they aren't wrapped in the new else block that's been put around the
typemap-lookup code.
The structure now looks like:
my $type = ...;
my $ntype = derived from $type;
etc
my $expr;
if (defined $output_code) {
$expr = $output_code;
}
elsif ($type =~ /^array\(([^,]*),(.*)\)/) {
$expr = "sv_setpvn($arg, (char *)$var, $nitems * sizeof($atype));";
}
else {
$expr = ... lookup typemap ...
}
Commit: ce06ec0315712351da32136bd619561d32aefa80
https://github.com/Perl/perl5/commit/ce06ec0315712351da32136bd619561d32aefa80
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: reindent block
The previous commit wrapped some code lines in an 'else' block. Reindent
to match. Whitespace-only.
Commit: d67c16b6c1ad30953b14861ebb82e8b8a2a486b0
https://github.com/Perl/perl5/commit/d67c16b6c1ad30953b14861ebb82e8b8a2a486b0
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: make array(type,n) handling more regular
The array pseudo-type used for return values, e.g.
array(int,5)
foo(...)
...
Is currently completely special-cased. This commit makes so it so that
instead, it just pretends that a typemap lookup was done, and that the
output template returned was (for example):
sv_setpvn($arg, (char *)$var, 5 * sizeof(int));
Then rather than emitting code like that directly, it now continues to
the general RETVAL-processing section. This means that any current or
future optimisations will be applied to it.
The test added by this commit shows that the generated code now uses the
minor RETVALSV optimisation. (It still doesn't use TARG yet).
Commit: 5ea0078f6382f64de2f1dcafe1fcb9e8279b5af7
https://github.com/Perl/perl5/commit/5ea0078f6382f64de2f1dcafe1fcb9e8279b5af7
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: generate_output: set $arg later
Move the $arg declaration and setting closer to its first use.
The previous commit removed an earlier need for it.
No functional changes.
Commit: cce3e102a675a2b70b8df9c1f2d668c70c242530
https://github.com/Perl/perl5/commit/cce3e102a675a2b70b8df9c1f2d668c70c242530
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: minor fixes for OUTPUT override code
Some of the refactoring earlier in this branch broke some edge cases.
This commit fixes those cases and adds tests.
In particular:
1) Optional typemap override code on OUTPUT lines is *not* eval-expanded
(unlike those on INPUT lines). So add a test for this, and don't bother
setting $expr in that case, since $expr is a meant to be a pre-eval
value. (This wasn't broken, but it wasn't tested, and setting $expr
didn't make any sense, and might cause new bugs further down the line).
2) In something like
int
foo(IN_OUTLIST int abc)
OUTPUT:
abc my_set(ST[0], RETVAL);
generate_output() is called *twice* for abc, once to update the first
arg with the current value of abc, and once to push a new mortal onto
the stack holding the current value of abc. The typemap override,
my_set(...), should only be used for the updating, not the pushing.
Commit: 3bf0cc5219de7e277e2b9e7f7e31867d85b1797a
https://github.com/Perl/perl5/commit/3bf0cc5219de7e277e2b9e7f7e31867d85b1797a
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: add xsub_stack_was_reset field
Add a boolean field, xsub_stack_was_reset, to the ParseXS class.
This field indicates that "XSprePUSH" has been emitted.
In more detail: XS has two main ways of adding return SVs to the stack.
For simple single-value-return XSUBs, SP is kept pointing at the top of
the current stack frame (i.e. pointing at the highest passed arg), then
the return value SV is stored at the base of stack frame (ST(0) = ...),
and then just before returning, the stack pointer is reset to base+1
(XSRETURN(1)).
However in the presence of OUTLIST params, or where where RETVAL can be
returned via the TARG optimisation, SP is instead reset to point to the
base of the stack frame via "XSprePUSH", then RETVAL and any OUTLIST
params are PUSH()ed onto the stack.
ParseXS used to keep track of this by checking in various places whether
there were any OUTLIST params. Instead this commit sets a boolean flag
if XSprePUSH has been emitted, then checks that flag for any further
code-emitting decisions.
Currently there is no difference between the two approaches (flag or
check OUTLIST count), but this commit will allow in future for things
to potentially become more fluid without breaking.
Commit: 91a102bc147c33004e836207b98f0fbad8f6165c
https://github.com/Perl/perl5/commit/91a102bc147c33004e836207b98f0fbad8f6165c
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: add xsub_targ_declared/usable
Add two new boolean fields to the ParseXS class:
xsub_targ_declared indicates that a dXSTARG was emitted;
xsub_targ_usable indicates that the TARG hasn't been used yet.
Currently ParseXS emits a dXSTARG early on if the typemap for RETVAL
indicates that it is TARG-optimisable. Later, when emitting code to
return RETVAL, the same check is made, and if so, a PUSHi() or whatever
is used to return an int/whatever more cheaply using TARG.
These two flags abstract out that a bit. It makes no difference yet,
but in future it would allow:
- a dXSTARG to be emitted later even if we couldn't have known
earlier that we could use it. (We can't just always move the declaration
to later, since various XS modules assume that TARG is available.)
- if/where there are more cases where using TARG might be useful, then
we avoid any risk of accidentally using the same targ to return two
different values.
Commit: fd8c51e1e6faf5487467e506dfe952927fda8dd1
https://github.com/Perl/perl5/commit/fd8c51e1e6faf5487467e506dfe952927fda8dd1
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: fix bool return code: RETVAL with magic
When generate_output() is asked to emit code which returns the value of
RETVAL when that value is boolean, then in the specific case of
$do_setmagic being true, it emits invalid code.
Now it so happens that for RETVAL, generate_output() is *never* called
with $do_setmagic set to true, so this is all a bit academic. But I'm
fixing it in case later refactoring tries to use this code path for
variables other than RETVAL. The fact that it can never happen is why
this commit doesn't include any tests.
The actual issue is that: while normally a bool return is simplified to
this single line of code:
ST(0) = boolSV(RETVAL);
when magic needs to be set then the value needs to be saved to a temporary
value, such as:
SV * RETVALSV;
RETVALSV = boolSV(RETVAL);
SvSETMAGIC(RETVALSV);
ST(0) = RETVALSV;
but the code had incorrectly concluded that it could use RETVAL instead:
RETVAL = boolSV(RETVAL);
SvSETMAGIC(RETVAL);
ST(0) = RETVAL;
Even though RETVAL is of type bool rather than SV*. With this fix,
RETVALSV is used.
Commit: 5d2ef0eaf7a723dba16eb54fa5badd3dac5d958f
https://github.com/Perl/perl5/commit/5d2ef0eaf7a723dba16eb54fa5badd3dac5d958f
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Utilities.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: expand PUSHi/u/n to { TARGi/u/n; PUSHs }
When ParseXS emits code which uses the TARG optimisation to push
an IV/UV/NV SV onto the stack as the return value, it currently
uses one of the PUSHx macros, e.g.
PUSHi((IV)RETVAL);
This commit makes it instead emit what that macro expands to, i.e.
TARGi((IV)RETVAL, 1); PUSHs(TARG);
This separates out the logically separate steps of:
1) setting the TARG SV to the return value;
2) pushing that SV onto the stack for return.
Splitting it out like this is functionally equivalent, but will assist
in future code refactoring, where the setting and pushing need to be
done separately, such as for PERL_RC_STACK builds.
For perls before 5.24.0 which don't have the TARGx macros, simple
backwards-compatible definitions are now added to the standard C
preamble in the generated .c file.
Note that TARGi etc include an optimisation for simple SVs. Their
definition is something along the lines of:
if (TARG is simple and no tainting) {
SvFLAGS(TARG) |= (SVf_IOK|SVp_IOK);
TARG->sv_u.svu_iv = TARGi_iv;
}
else
sv_setiv_mg(targ, i);
I have not attempted to reproduce this logic for the pre-5.24.0 back-compat
macros: instead these are just:
#define TARGi(iv, do_taint) sv_setiv_mg(TARG, iv)
etc, which mimic the pre-5.24 definitions of PUSHi etc:
#define PUSHi(i) sv_setiv(TARG, (IV)(i)); PUSHTARG;
One subtlety is that in the old macros, the sv_setiv didn't do set magic,
while the PUSHTARG did. In the new scheme it's the other way round; TARGi
or sv_setiv_mg() do set magic, while the PUSHs(TARG) doesn't.
Commit: 8cbb0379959f6f77acf2168af927fe73be9fac35
https://github.com/Perl/perl5/commit/8cbb0379959f6f77acf2168af927fe73be9fac35
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: expand PUSHp to { sv_setpvn_mg; PUSHs }
When ParseXS emits code which uses the TARG optimisation to push
a PV onto the stack as the return value, it currently uses one of two
approaches, depending on whether there is a length argument:
1) PUSHp(val, len);
2) sv_setpv(TARG, val); PUSHTARG;
This commit expands and simplifies the output for those macros. In
particular, separating out the TARG-setting and TARG-pushing operations
to make future refactoring easier.
For the first, this commit expands the PUSHp() macro so that the emitted
code becomes:
sv_setpvn(TARG, val, len); SvSETMAGIC(TARG); PUSHs(TARG);
and then moves the magic setting into the function call:
sv_setpvn_mg(TARG, val, len); PUSHs(TARG);
For the second, it expands the PUSHTARG:
sv_setpv(TARG, val); SvSETMAGIC(TARG); PUSHs(TARG);
and again, then moves the magic setting into the function call:
sv_setpv_mg(TARG, val); PUSHs(TARG);
Commit: c56758f3cd876d67b4d212036bb5d63dcfc994fb
https://github.com/Perl/perl5/commit/c56758f3cd876d67b4d212036bb5d63dcfc994fb
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: pull out common TARG PUSHs()
The last couple of commits have made it so that all branches of the TARG
optimisation end with
print "\tPUSHs(TARG);\n";
so pull all these out into a single print at the end.
Commit: 3c15d36d0d01a6d5191f14d4584b3eb9719f7179
https://github.com/Perl/perl5/commit/3c15d36d0d01a6d5191f14d4584b3eb9719f7179
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: TARG opt: do eval only once
For the TARG optimisation, the typemap parser has detected typemaps
of the form sv_setiv(), sv_setpvn() etc and split them out into their
components. These components will then be variable-expanded using eval,
then put back in a modified version of the original call.
So for example, for a typemap of
sv_setiv($arg, (IV)$var);
we would do the equivalent of:
$what = '(IV)$var'; # extracted out by typemap parser
$what = $self->eval_output_typemap_code($what, {var => $var, ...});
print "TARGi($what, 1);\n";
However for the sv_setpvn() case, there is an extra length arg.
Formerly this was variable-expanded using a *second* eval. This commit
combines both into a single eval, making the code simpler. So for this
typemap:
sv_setpvn($arg, (char *)&$var, sizeof($var));
it now does the equivalent of:
$what = '(char *)&$var'; # extracted out by typemap parser
$tsize = ', sizeof($var)'; # extracted out by typemap parser
$what = $self->eval_output_typemap_code("$what$tsize", {var => $var, ...});
print "sv_setpvn_mg(TARG, $what);\n";
Commit: 805d04f3dfc2ca31aa6fa698ca9b2a6f62547b47
https://github.com/Perl/perl5/commit/805d04f3dfc2ca31aa6fa698ca9b2a6f62547b47
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: pull out common XSprePUSH emit
The two branches of the TARG optimisation both emit a 'XSprePUSH;' line.
This commit hoists those two identical blocks of code to outside the
if/else.
For the TARGi/u/n case, as a side effect it changes the ordering of the
lines of C code from:
XSprePUSH; /* reset stack pointer to base of frame */
TARGu((IV)RETVAL, 1);
PUSHs(TARG);
to
TARGu((IV)RETVAL, 1);
XSprePUSH; /* reset stack pointer to base of frame */
PUSHs(TARG);
Which is functionally the same.
For the sv_setpv/sv_setpvn cases, there is no change in output (so this
commit actually makes things more consistent).
Commit: 4834a2e96a34d3e4e5963a6f2ea339182468073b
https://github.com/Perl/perl5/commit/4834a2e96a34d3e4e5963a6f2ea339182468073b
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: TARG opt: eval whole expression
Given a typemap like
sv_setiv($arg, (IV)$var);
the TARG optimisation currently extracts out the '(IV)$var' part of it,
evals that as a double-quoted string in order to variable-expand '$var'
etc, then constructs a new expression using that result, e.g.
'TARGi((IV)RETVAL)'.
This commit changes it so that the eval expansion comes *after* the
reconstruction. So before:
$what = '(IV)$var';
$what = eval qq("$what");
$result = "TARGi($what)";
and after:
$what = '(IV)$var';
$what = "TARGi($what)";
$result = eval qq("$what");
The result should be the same, but it makes the code closer to how
RETVAL is handled in the rest of generate_output().
Commit: 70664836f534b687d1aef4bc0af19b18047a1aaa
https://github.com/Perl/perl5/commit/70664836f534b687d1aef4bc0af19b18047a1aaa
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: don't XSprePUSH for TARG returns
ParseXS currently generates two kinds of C code to return RETVAL.
For the general case, the code looks like (give or take some extra
messing around with sv_newmortal(), SvSETMAGIC() etc):
sv_setfoo(RETVALSV, (foo)RETVAL); /* from the typemap template */
ST(0) = RETVALSV;
XSRETURN(1);
While for the "use TARG instead of a new mortal" optimisation, it
looks like:
TARGi((foo)RETVAL); /* modified typemap template to set TARG efficiently */
XSprePUSH;
PUSHs(TARG);
XSRETURN(1);
This commit makes the TARG optimisation use the first form too. As well
as being marginally more efficient, it will help with refactoring
ParseXS: soon the TARG optimisation branch and the general branch should
be able to be mostly combined. It's also more friendly to implementing
PERL_RC_STACK eventually.
In more detail:
On entry to an XSUB, ax is set to the offset to the first arg (i.e.
ST(0)), and SP/sp is set to point to the last (topmost) arg.
During execution of the body of the XSUB, the args are left on the
stack. Then when putting return values on the stack (typically just one
- RETVAL - although rarely others may be pushed too via OUTLIST), then
the general code expands to something like:
*(PL_stack_base + ax) = RETVALSV; /* ST(0) = RETVALSV; */
PL_stack_sp = PL_stack_base + ax; /* XSRETURN(1); */
Which effectively replaces the first arg with RETVAL and then blows the
rest of the args away.
While the TARG code does:
sp = PL_stack_base + ax - 1; /* XSprePUSH; */
*++sp = TARG; /* PUSHs(TARG); */
PL_stack_sp = PL_stack_base + ax; /* XSRETURN(1); */
i.e. blow all the args away, then push RETVAL.
The resetting and incrementing of sp is unnecessary: it is just a
hangover from when the TARG optimisation used PUSHi() etc.
Note that in the presence of at least one OUTLIST param, an XSprePUSH
is still emitted. The stack is reset before any value(s) are output;
the 'ST(0) = ...' actually modifies the stack slot *above* sp, but then
'SP++' is immediately emitted after that.
Commit: daaa23d88207e689c13974742e13b538d33ec96e
https://github.com/Perl/perl5/commit/daaa23d88207e689c13974742e13b538d33ec96e
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: remove dead SvSETMAGIC()-emitting code
In the big chunk of code in generate_output() which is responsible for
emitting the C code which creates a mortal SV and then sets its value to
RETVAL and pushes it on the stack, there is a bunch of code to emit
"SvSETMAGIC(RETVALSV);" or similar if $do_setmagic is true.
However, for RETVAL:
a) $do_setmagic should never be true; and
b) even if it was, it would be pointless to call set magic on a fresh
temporary SV.
So this commit removes all the code which handles $do_setmagic in the
RETVAL branch, and instead adds a death("Internal error: ...") for if
$do_setmagic does happen to be true.
This commit should produce no changes to the generated C code.
The next commit will handle a similar situation for setting magic when
the TARG optimisation is being used.
Commit: 85e74a86c2002d5b1ab0303c973ebe327b4b4b41
https://github.com/Perl/perl5/commit/85e74a86c2002d5b1ab0303c973ebe327b4b4b41
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: don't set magic on TARG return value.
There is a chunk of code in generate_output() which is responsible for
emitting the C code which grabs the targ from the pad, sets its value to
RETVAL, and pushes it on the stack.
The value setting can be one of two forms:
TARGi((IV)RETVAL) /* and TARGu, TARGn */
sv_setpvn_mg(TARG, RETVAL, length(retval))
The TARGi/u/n expand to:
if (TARG is simple)
update it directly
else
sv_setiv_mg(targ, i)
and similar.
However, for RETVAL:
a) $do_setmagic should never be true; and
b) even if it was, it would be pointless to call set magic on a TARG.
So this commit changes the sv_setpv_mg() to sv_setpv() and similarly
for sv_setpvn().
Note that TARGi/u/n still calls set magic in the non-shortcut case,
but I'm not worried about the slight inefficiency, as it shouldn't happen
very often.
Note that the previous commit did the same for RETVAL in the
non-TARG-optimisation case. Unlike the previous commit, this one *does*
affect what C code is generated.
Commit: 200f198d3339b2e68044362db266dbbe3eb0dea1
https://github.com/Perl/perl5/commit/200f198d3339b2e68044362db266dbbe3eb0dea1
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: simplify RETVAL logic
Simplify the code in generate_output() which emits C code to return the
value of RETVAL. This also prepares it for some changes which will
follow in the next commit.
Mainly it adds the $retvar lexical, which keeps track of what C var (or
expression) should be used when setting values or calling sv_2mortal()
etc: i.e. one of 'RETVALSV', 'RETVAL', or 'ST(0)'. (And might be 'TARG'
too in the next commit).
This replaces a couple of bool flags.
Should be no functional changes.
Commit: cb466ff3921e395ad25ed96070568502cf59afbc
https://github.com/Perl/perl5/commit/cb466ff3921e395ad25ed96070568502cf59afbc
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: make TARG code less exceptional
There is a block of code in generate_output() which for some typemaps of
the general form sv_set[ivnp]vn?($arg, $val), uses TARG rather than a
new mortal to return the value; and which in addition, for the [iuv]
cases uses TARGi() etc to set the value more efficiently sometimes.
Currently this is handled in an entirely separate 'if' block in
generate_output(), including doing its own: evalling the typemap,
emitting C code, and returning.
This commit changes it so that the TARG optimisation is instead handled
within the general RETVAL-handling code.
This makes the code simpler and easier to maintain.
The main differences in the old and new ways are that rather than:
- constructing and evalling a whole new typemap: e.g. ditching
'sv_setiv($arg, $val)', replacing it with 'TARGi($val, 1)' and then
evalling it to get e.g. 'TARGi((IV)RETVAL, 1)',
- we instead use the post-eval version of the standard typemap,
'sv_setiv(RETVALSV, (IV)RETVAL)', and then for the specific cases of
[iuv], apply a regex to convert it to 'TARGi((IV)RETVAL, 1)'. This
should be functionally the same, but may have minor white space
changes.
By using the standard eval code path, the typemap is evalled with the
full complement of vars such as $ntype, $num etc, rather than just $var
and $type. Whether this better or worse is debatable. Arguably the
standard eval sets too many vars (as a historical accident), while the
(just removed) TARG-specific eval arguably sets too few vars.
For the sv_setpv() and sv_setpvn() cases, we don't modify the result,
except to change 'RETVALSV' to 'TARG'. This now causes typecasts which
were in the original typemap to be kept, whereas before they were
striped. So
sv_setpv(TARG, ....)
becomes
sv_setpv((SV*)TARG, ....)
Which shouldn't make any difference since TARG is already SV*.
Apart from the white space and restoration of any cast, and the changes
in vars available to the eval, there should be no other functional
changes.
I've also added code which emits a late 'dXSTARG' if one hasn't already
been emitted earlier in the XSUB body, but for now, it should already
have been emitted earlier always. But this allows for potential future
expansions to what can use the TARG.
Commit: 555854b0faab7a933c97291a438f436e1aaf6e5a
https://github.com/Perl/perl5/commit/555854b0faab7a933c97291a438f436e1aaf6e5a
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: clean up output code comments
Recent commits have extensively messed with generate_output().
This commit updates and clean ups all the code comments in that area,`
and moves a couple of lexical var declarations closer to where they're
first used.
Commit: cb3a820e9c2b35db11899cfbd63835e7606f1794
https://github.com/Perl/perl5/commit/cb3a820e9c2b35db11899cfbd63835e7606f1794
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: add more OUTLIST tests
Add several tests where an OUTLIST param is the first or second value
to be returned on the stack.
The next commit will make OUTLIST params use the same code path as the
RETVAL return code generation, so add lots of tests now to see what (if
anything) changes. In theory, merging the code paths opens up the
possibility of TARG being used to return an OUTLIST value for example.
Commit: 686fc8d6991365de639057605628d7e19a033477
https://github.com/Perl/perl5/commit/686fc8d6991365de639057605628d7e19a033477
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: regularise/optimise OUTLIST code gen
In an XSUB like
int
foo(OUTLIST int A, OUTLIST int B)
...
C code is emitted to push SVs onto the stack containing the values of
RETVAL, A and B. So in principle, something like:
XSprePUSH;
EXTEND(SP,3);
PUSHs(sv_newmortal());
sv_setiv(ST(0), (IV)RETVAL);
PUSHs(sv_newmortal());
sv_setiv(ST(1), (IV)A);
PUSHs(sv_newmortal());
sv_setiv(ST(2), (IV)B);
However, RETVAL and OUTLIST params are currently handled by two separate
branches within generate_output().
The OUTLIST branch always just emits a PUSHs() / sv_setX() pair.
The RETVAL branch on the other hand includes a number of optimisations,
such as using TARG instead of sv_newmortal(), using TARGi() rather than
sv_setiv() to set the value of the SV, using SV* RETVALSV as an
intermediate variable, not copying the SV when the typemap returns an
SV, and skipping a mortalise when the typemap returns an immortal SV.
This commit deletes the OUTLIST branch, and instead makes OUTLIST params
use the RETVAL branch. This immediately makes most of the RETVAL
optimisations available to OUTLIST params. In particular, if the XSUB is
void return type, then the TARG is still available to be used for the
first OUTLIST param.
This isn't as exciting as it may first seem, as very little real XS code
actually uses OUTLIST params. But it simplifies and regularises the code
in generate_output(), and means that any future added RETVAL
optimisations will automatically apply to OUTLIST values too.
Note that some OUTPUT typemaps look like:
T_BOOL
${"$var" eq "RETVAL" ? \"$arg = boolSV($var);" : \"sv_setsv($arg,
boolSV($var));"}
which for now will carry on using the inefficient sv_setsv() branch for
non-RETVAL returns, so will copy rather than returning an immortal
directly.
Commit: 48fac9e7c667c9f3cf2c45cc3e73cc24fe459f7c
https://github.com/Perl/perl5/commit/48fac9e7c667c9f3cf2c45cc3e73cc24fe459f7c
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm
M dist/ExtUtils-ParseXS/t/517-t-targetable.t
Log Message:
-----------
ParseXS: add OutputMap::targetable_legacy() method
Add a Typemaps::OutputMap::targetable_legacy() method which is,
initially, just an exact copy of the existing targetable() method. Then
use the legacy method to determine whether to emit an early dXSTARG,
while continue to use the targetable() method to determine whether to
emit a late dXSTARG.
Background: until recently, the TARG optimisation was used specifically
only where the typemap entry for RETVAL's type was one of
sv_set{iv,uv,nv,pv,pvn}. This was detected by the targetable() method,
and if true, a dXSTARG was emitted near the start of the XSUB's body,
then the sv_setiv(ST(0)), RETVAL) or whatever near the end of the XSUB
was replaced with C<TARGi(RETVAL); PUSHs(TARG)> or similar.
Recent changes have expanded where TARG can be used, sometimes where the
usage can't be detected early. In these cases, a dXSTARG is instead
emitted in a tight scope near the end of the XSUB, e.g.
{ dXSTARG; sv_setfoo(TARG, bar); PUSHs(TARG); }
Ideally the early dXSTARG would never be emitted and dXSTARG would just
be emitted where and when it is required. However, some CPAN XS code
assumes that TARG has been declared, e.g. in order to override the
normal C<OUTPUT: RETVAL> behaviour, or to add a PERL_UNUSED_ARG(TARG) in
PPCODE for an XSUB which has a declared return value.
So the idea behind this commit is that targetable_legacy() will become
fossilised and will cause an early dXSTARG to continue being emitted
under the same circumstances; while targetable() will change over time,
allowing a late dXSTARG in more circumstances.
Commit: 764fbc4cd10c79bae633b9f3625c62942c9a3998
https://github.com/Perl/perl5/commit/764fbc4cd10c79bae633b9f3625c62942c9a3998
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
M dist/ExtUtils-ParseXS/t/517-t-targetable.t
Log Message:
-----------
ParseXS: make OutputMap::targetable a class method
Currently, ExtUtils::Typemaps::OutputMap::targetable() is an object
method which examines the typemap template associated with the object
and determines whether it is suitable for the TARG optimisation. If so,
it returns a hash containing the parsed components of the
sv_setXv(...,...) string that were found in the typemap.
This commit changes this method in two ways.
First, targetable() now just returns a boolean, as the components are no
longer used.
Second, it converts targetable() into a class method, where the template
string is instead passed as a parameter.
This second change allows us to use the TARG optimisation even for
template code which wasn't derived from a typemap. In particular, for
the array() pseduo-type. For example in:
array(int,5)
foo(...)
CODE:
...
Formerly the 'array(int,5)' pseudo-type was converted into a template
like:
sv_setpvn($arg, (char*)$var, 5 * sizeof(int))
which was evalled and emitted as normal. But because that template
wasn't derived from a typemap, it wasn't eligible for TARG. Following
this commit, it is.
Commit: 586d86a6d35a8274e54a4c527b8456d6e51c63f9
https://github.com/Perl/perl5/commit/586d86a6d35a8274e54a4c527b8456d6e51c63f9
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm
M dist/ExtUtils-ParseXS/t/517-t-targetable.t
Log Message:
-----------
ParseXS: targetable(): split into 2- and 3-arg
The code in ExtUtils::Typemaps::OutputMap->targetable() which looks
for typemap template code like
sv_setiv($arg, RETVAL);
sv_setpvn($arg, RETVAL, strlen(RETVAL));
is currently a bit rough and matches against various badly-formed
strings.
This commit changes it so that 2-arg functions like sv_setiv() are only
matched if they have 2 args, and sv_setpvn() only if it has three args.
Previously it would allow either to have 2 or 3 args.
This commit breaks a couple of recently-added tests for embedded
double-quoted strings because it turns out the regexes didn't actually
handle quotes, but matched anyway due to the laxness of the match.
This will be fixed shortly.
This commit is unlikely to affect any real XS code, because the code in
typemaps tends to be well-formed.
Commit: 86d470df739b57f6ab85353b2d9664bf9e1172ea
https://github.com/Perl/perl5/commit/86d470df739b57f6ab85353b2d9664bf9e1172ea
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm
M dist/ExtUtils-ParseXS/t/517-t-targetable.t
Log Message:
-----------
ParseXS: targetable(): parse C strings
In the pattern-matching code which looks for candidates for the TARG
optinisation in typemap entries like:
sv_setiv($arg, RETVAL);
sv_setpvn($arg, RETVAL, strlen(RETVAL));
make C double-quoted strings such as "a,b" and "a,\",c" be parsed,
so that for example commas within double-quotes aren't mis-parsed
as an arg separator.
This commit is unlikely to affect any real XS code, but is added for
completeness.
It also changes a (??{ $bal }) to $bal_no_comma because
a) the third arg shouldn't have any commas;
b) there's no need for the (??{}) recursion yet - that's already
done within $bal/$bal_no_comma.
Commit: 79a72cdb912a9c41ea5e69f83887f354d644f309
https://github.com/Perl/perl5/commit/79a72cdb912a9c41ea5e69f83887f354d644f309
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
M dist/ExtUtils-ParseXS/t/517-t-targetable.t
Log Message:
-----------
ParseXS: test for targetable *after* eval
Previously, checking for whether a typemap code entry was suitable
for the TARG optimisation was done *before* eval-expanding the template;
so it would look for code like, e.g.
sv_setiv($arg, ...);
This commit changes it so that it now examines the code string *after*
expansion, so it now looks for strings like
sv_setiv(RETVALSV, ...);
The advantage of this is that a complex typemap entry such as
T_MYINT
${ "$var" eq "RETVAL" ? \"$arg = myint($var)"
: \"sv_setiv($arg, $var);" }
would now be a candidate.
Note that nothing in the current standard typemap, nor in any of the
XS code bundled with perl, actually benefits from this currently. So
it's more of a potential rather than an actual efficiency improvement.
Note also that ParseXS currently always expands $arg to 'RETVALSV', but
I've included a few other options to match, such as 'ST(N)', in case
that ever changes.
Commit: b3a38b0ca90d52d74fd395981ad25a800dabae66
https://github.com/Perl/perl5/commit/b3a38b0ca90d52d74fd395981ad25a800dabae66
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/Typemaps/OutputMap.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
M dist/ExtUtils-ParseXS/t/517-t-targetable.t
Log Message:
-----------
ParseXS: make more sv_setfoo() fns TARG candidates
Currently sv_set(iv|uv|nv|pv|pvn) are candidates for using TARG for the
return SV rather than creating a new mortal. In addition,
sv_set(iv|uv|nv) are candidates for using TARG[iun] to more efficiently
set the value of that TARG SV.
This commit does two things.
First, it extends the list of eligible functions to use TARG.
I basically went through embed.fnc looking for functions of the form
sv_set* and ignored the weird ones or ones which could leave TARG as
anything other than a simple scalar (in particular, TARG mustn't become
an RV or the referent will have its life extended to the life of the
TARG). I added:
- the _mg variants of the sv_set(iv|uv|nv|pv|pvn) functions.
Since TARG shouldn't have set magic, it should make no difference
whether we call set magic or not.
- the 1-arg sv_set_(undef|false|true) functions. These relatively new
functions don't take a parameter and so are unlikely to be used in a
typemap, but are included for completeness.
- sv_set_bool(). This is a relatively new function but might start to
appear in typemaps in future.
- sv_setpv_bufsize(). A bit obscure, but why not!
Secondly, it extends the candidates for the use of TARG[iuv] to the _mg
variants of sv_set[iun]v.
Currently no typemaps or XS code in core uses these extra functions,
but they might on CPAN or in the future.
Commit: 32a1acaccccf4a8acad144f92e27914c6befbe95
https://github.com/Perl/perl5/commit/32a1acaccccf4a8acad144f92e27914c6befbe95
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: flatten if/else
The tail half of generate_output() looks like
if (cond) {
long block of code
}
else {
short block of code
}
return;
This commit refactors it to be
if (!cond) {
short block of code
return;
}
long block of code
return;
Next commit will reindent
Commit: 5efe61c90514b1e374dc1f2ae11953e0ce1b172a
https://github.com/Perl/perl5/commit/5efe61c90514b1e374dc1f2ae11953e0ce1b172a
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: re-indent code block
Re-indent block after previous commit removed a scope.
Whitespace-only.
Commit: 2f1a8301037f962b2a2f18fdeb1de990387cc66b
https://github.com/Perl/perl5/commit/2f1a8301037f962b2a2f18fdeb1de990387cc66b
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: don't always extend stack with OUTLIST
Normally when an XSUB returns a *single* RETVAL value, we skip
emitting an EXTEND(SP,1), because the pp_entersub() will have earlier
been called with at least a GV or CV on the stack.
But it always extended the stack if there were any OUTLIST values that
needed pushing and returning. This commit makes it take into account
that a GV/CV plus at least min_args arguments were already on the stack
when pp_entersub() was called, so only extend the stack if more values
than that need returning.
So for example this no longer emits an EXTEND(SP,1)
void
foo(OUTLIST int i)
(This is unlikely to speed up much real-life code, as nobody seems to
actually use OUTLIST.)
Commit: d094cddc53f16a9b1cf6a975ab2a0e8bc7f881a4
https://github.com/Perl/perl5/commit/d094cddc53f16a9b1cf6a975ab2a0e8bc7f881a4
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/t/typemap
Log Message:
-----------
ParseXS: sync test typemap with system typemap
The typemap file used for testing ExtUtils::ParseXS, t/typemap, hasn't
(for many years) been updated when the typemap bundled with perl,
lib/ExtUtils/typemap, gets updated.
This commit resyncs them by overwriting the test file with the system
file.
In the long term they really aught to be unified in some fashion.
Commit: fa68a2b5b4df83f6d62c53f83827f015b8527643
https://github.com/Perl/perl5/commit/fa68a2b5b4df83f6d62c53f83827f015b8527643
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/t/001-basic.t
Log Message:
-----------
ParseXS: fix OUTLIST code gen for SV*
About 12 commits ago in this branch, I moved OUTLIST return-code
generation into the same code path as for that done for RETVAL.
This allows OUTLIST vars to potentially take advantage of some of the
optimisations done for RETVAL, such as using TARG rather than
sv_newmortal().
Unfortunately that commit missed a couple of places in the RETVAL code
path which had the variable name hard-coded as 'RETVAL'. This commit
fixes that by always using $var.
It would only have affected code which used an OUTLIST var of type SV*
on a non-void XSUB where the T_SV OUTPUT typemap entry had also been
overridden to:
T_SV
$arg = $var;
In that specific case, an XSUB like:
int
foo(OUTLIST SV* A)
was generating bad code like:
int RETVAL;
SV* A;
...
RETVAL = A;
RETVAL = sv_2mortal(RETVAL);
ST(1) = RETVAL;
It now emits:
int RETVAL;
SV* A;
...
A = sv_2mortal(A);
ST(1) = A;
This commit also adds a number of new tests for OUTLIST vars where the
typemap has an assign.
It also fixes the test framework in t/001-basic.t to capture and
display the error if the test code gives an eval error.
Commit: 9861cb32f9c418522f4450b535c40d8ff8ac9266
https://github.com/Perl/perl5/commit/9861cb32f9c418522f4450b535c40d8ff8ac9266
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: update code comments for generate_output()
Do a general rewrite of all the code comments directly above and in this
sub, to reflect all the recent refactoring work.
Commit: f886b5741c5d360d442105aa8ea509c4ef7b83ce
https://github.com/Perl/perl5/commit/f886b5741c5d360d442105aa8ea509c4ef7b83ce
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: tweak xsub_targ_* fields
I recently added two fields to the ParseXS object,
xsub_targ_declared
xsub_targ_usable
and a few weeks later I found myself confused by them, so this commit
renames them and changes their functionality slightly.
xsub_targ_declared -> xsub_targ_declared_early
This flag now indicates solely that a dXSTARG was emitted at the *start*
of the XSUB in a wide scope. It no longer indicates also that a dXSTARG
been emitted later in a narrow scope.
xsub_targ_usable -> xsub_targ_used
Inverts the logic, and now indicates purely whether we've already
used TARG to return a value, rather than whether it's still available
to be used. That was getting muddied up with whether dXSTARG had been
emitted early (because if it hadn't, is TARG usable?).
Should be no functional change to the emitted C code.
Commit: 3ad46428e5e616f072ff7e2756a6c7770e527b07
https://github.com/Perl/perl5/commit/3ad46428e5e616f072ff7e2756a6c7770e527b07
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
Log Message:
-----------
ParseXS: refactor: make generate_output Param meth
Rename generate_output() to as_output_code() and make it a method
in the ExtUtils::ParseXS::Node::Param class (it was formerly
an ExtUtils::ParseXS method).
As well as the rename, this commit mainly does s/$self/$pxs/g and
s/$param/$self/g.
The next commit will move this method into Node.pm.
Commit: 728cdf31885d659fa454c407fa433ad108c27143
https://github.com/Perl/perl5/commit/728cdf31885d659fa454c407fa433ad108c27143
Author: David Mitchell <da...@iabyn.com>
Date: 2025-01-12 (Sun, 12 Jan 2025)
Changed paths:
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS.pm
M dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Node.pm
Log Message:
-----------
ParseXS: refactor move as_output_code into Node.pm
The previous commit made as_output_code() be a method of
ExtUtils::ParseXS::Node::Param; now move it into Node.pm where it
belongs.
No functional changes; just a literal cut+paste, except for no longer
needing the full package name in the sub declaration, so
sub ExtUtils::ParseXS::Node::Param::as_output_code { ... }
becomes
sub as_output_code { ... }
It also updates the code comments for as_code() to add mention that
there's now also a related as_output_code() method.
Compare: https://github.com/Perl/perl5/compare/2fd3cd18765c%5E...728cdf31885d
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
