represented what current perl programs do, and measurably reported whether
tweaks to the core improve, degrade or don't really affect performance, to
guide people attempting to optimise the guts of perl. Gisle would welcome
-new tests for perlbench.
+new tests for perlbench. Steffen Schwingon would welcome help with
+L<Benchmark::Perl::Formance>
=head2 fix tainting bugs
Some platforms mandate that you provide a list of a shared library's external
symbols to the linker, so the core already has the infrastructure in place to
-do this for generating shared perl libraries. My understanding is that the
-GNU toolchain can accept an optional linker specification file, and restrict
-visibility just to symbols declared in that file. It would be good to extend
-F<makedef.pl> to support this format, and to provide a means within
-C<Configure> to enable it. This would allow Unix users to test that the
+do this for generating shared perl libraries. Florian Ragwitz has been working
+to offer this for the GNU toolchain, to allow Unix users to test that the
export list is correct, and to build a perl that does not pollute the global
namespace with private symbols, and will fail in the same way as msvc or mingw
-builds or when using PERL_DL_NONLAZY=1.
+builds or when using PERL_DL_NONLAZY=1. See the branch smoke-me/rafl/ld_export
=head2 Cross-compile support
-Currently C<Configure> understands C<-Dusecrosscompile> option. This option
+We get requests for "how to cross compile Perl". The vast majority of these
+seem to be for a couple of scenarios:
+
+=over 4
+
+=item *
+
+Platforms that could build natively using F<./Configure> (I<e.g.> Linux or
+NetBSD on MIPS or ARM) but people want to use a beefier machine (and on the
+same OS) to build more easily.
+
+=item *
+
+Platforms that can't build natively, but no (significant) porting changes
+are needed to our current source code. Prime example of this is Android.
+
+=back
+
+There are several scripts and tools for cross-compiling perl for other
+platforms. However, these are somewhat inconsistent and scattered across the
+codebase, none are documented well, none are clearly flexible enough to
+be confident that they can support any TARGET/HOST plaform pair other than
+that which they were developed on, and it's not clear how bitrotted they are.
+
+For example, C<Configure> understands C<-Dusecrosscompile> option. This option
arranges for building C<miniperl> for TARGET machine, so this C<miniperl> is
-assumed then to be copied to TARGET machine and used as a replacement of full
-C<perl> executable.
-
-This could be done little differently. Namely C<miniperl> should be built for
-HOST and then full C<perl> with extensions should be compiled for TARGET.
-This, however, might require extra trickery for %Config: we have one config
-first for HOST and then another for TARGET. Tools like MakeMaker will be
-mightily confused. Having around two different types of executables and
-libraries (HOST and TARGET) makes life interesting for Makefiles and
-shell (and Perl) scripts. There is $Config{run}, normally empty, which
-can be used as an execution wrapper. Also note that in some
-cross-compilation/execution environments the HOST and the TARGET do
-not see the same filesystem(s), the $Config{run} may need to do some
-file/directory copying back and forth.
+assumed then to be copied to TARGET machine and used as a replacement of
+full C<perl> executable. This code is almost 10 years old. Meanwhile, the
+F<Cross/> directory contains two different approaches for cross compiling to
+ARM Linux targets, relying on hand curated F<config.sh> files, but that code
+is getting on for 5 years old, and requires insider knowledge of perl's
+build system to draft a F<config.sh> for a new platform.
+
+Jess Robinson has sumbitted a grant to TPF to work on cleaning this up.
=head2 Split "linker" from "compiler"
On these systems, it might be the default compilation mode, and there
is currently no guarantee that passing no use64bitall option to the
Configure process will build a 32bit perl. Implementing -Duse32bit*
-options would be nice for perl 5.14.
+options would be nice for perl 5.18.0.
=head2 Profile Perl - am I hot or not?
One piece of Perl code that might make a good testbed is F<installman>.
-=head2 Allocate OPs from arenas
-
-Currently all new OP structures are individually malloc()ed and free()d.
-All C<malloc> implementations have space overheads, and are now as fast as
-custom allocates so it would both use less memory and less CPU to allocate
-the various OP structures from arenas. The SV arena code can probably be
-re-used for this.
-
-Note that Configuring perl with C<-Accflags=-DPL_OP_SLAB_ALLOC> will use
-Perl_Slab_alloc() to pack optrees into a contiguous block, which is
-probably superior to the use of OP arenas, esp. from a cache locality
-standpoint. See L<Profile Perl - am I hot or not?>.
-
=head2 Improve win32/wince.c
Currently, numerous functions look virtually, if not completely,
Currently the %ENV entries are always byte strings.
See L</"Virtualize operating system access">.
+(See RT ticket #113536 for information on Win32's handling of %ENV,
+which was fixed to work with native ANSI codepage characters in the
+environment, but still doesn't work with other characters outside of
+that codepage present in the environment.)
+
=head2 Unicode and glob()
Currently glob patterns and filenames returned from File::Glob::glob()
huge speed-up. Only minimal work was done on the optimizer when utf8
was added, with the result that the synthetic start class often will
fail to narrow down the possible choices when given non-Latin1 input.
-
-=head2 Properly Unicode safe tokeniser and pads.
-
-The tokeniser isn't actually very UTF-8 clean. C<use utf8;> is a hack -
-variable names are stored in stashes as raw bytes, without the utf-8 flag
-set. The pad API only takes a C<char *> pointer, so that's all bytes too. The
-tokeniser ignores the UTF-8-ness of C<PL_rsfp>, or any SVs returned from
-source filters. All this could be fixed.
+Karl Williamson has been working on this - talk to him.
=head2 state variable initialization in list context
=head2 lexical aliases
-Allow lexical aliases (maybe via the syntax C<my \$alias = \$foo>.
-
-=head2 entersub XS vs Perl
-
-At the moment pp_entersub is huge, and has code to deal with entering both
-perl and XS subroutines. Subroutine implementations rarely change between
-perl and XS at run time, so investigate using 2 ops to enter subs (one for
-XS, one for perl) and swap between if a sub is redefined.
+Allow lexical aliases (maybe via the syntax C<my \$alias = \$foo>).
=head2 Self-ties
See also L</"Extend PerlIO and PerlIO::Scalar">.
-=head2 Store the current pad in the OP slab allocator
-
-=for clarification
-I hope that I got that "current pad" part correct
-
-Currently we leak ops in various cases of parse failure. I suggested that we
-could solve this by always using the op slab allocator, and walking it to
-free ops. Dave comments that as some ops are already freed during optree
-creation one would have to mark which ops are freed, and not double free them
-when walking the slab. He notes that one problem with this is that for some ops
-you have to know which pad was current at the time of allocation, which does
-change. I suggested storing a pointer to the current pad in the memory allocated
-for the slab, and swapping to a new slab each time the pad changes. Dave thinks
-that this would work.
-
=head2 repack the optree
Repacking the optree after execution order is determined could allow
removal of NULL ops, and optimal ordering of OPs with respect to cache-line
-filling. The slab allocator could be reused for this purpose. I think that
+filling. I think that
the best way to do this is to make it an optional step just before the
completed optree is attached to anything else, and to use the slab allocator
-unchanged, so that freeing ops is identical whether or not this step runs.
+unchanged--but allocate a single slab the right size, avoiding partial
+slabs--, so that freeing ops is identical whether or not this step runs.
Note that the slab allocator allocates ops downwards in memory, so one would
have to actually "allocate" the ops in reverse-execution order to get them
contiguous in memory in execution order.
be done 1st in XS, and using B::Generate to patch the new OP into the
optrees.
-=head2 Add C<00dddd>
+=head2 Add C<0odddd>
It has been proposed that octal constants be specifiable through the syntax
C<0oddddd>, parallel to the existing construct to specify hex constants
=head1 Big projects
Tasks that will get your name mentioned in the description of the "Highlights
-of 5.14"
+of 5.18.0"
=head2 make ithreads more robust
-Generally make ithreads more robust. See also L</iCOW>
+Generally make ithreads more robust.
This task is incremental - even a little bit of work on it will help, and
will be greatly appreciated.
Fix Perl_sv_dup, et al so that threads can return objects.
-=head2 iCOW
-
-Sarathy and Arthur have a proposal for an improved Copy On Write which
-specifically will be able to COW new ithreads. If this can be implemented
-it would be a good thing.
-
-=head2 (?{...}) closures in regexps
-
-Fix (or rewrite) the implementation of the C</(?{...})/> closures.
-
=head2 Add class set operations to regexp engine
Apparently these are quite useful. Anyway, Jeffery Friedl wants them.
[ Each and every one of these may be obsolete, but they were listed
in the old Todo.micro file]
-
-=head2 make creating uconfig.sh automatic
-
-=head2 make creating Makefile.micro automatic
-
=head2 do away with fork/exec/wait?
(system, popen should be enough?)
https://perl5.git.perl.org / perl5.git / blobdiff