|
NAMEB::CC - Perl compiler's optimized C translation backendSYNOPSISperl -MO=CC[,OPTIONS] foo.pl DESCRIPTIONThis compiler backend takes Perl source and generates C source code corresponding to the flow of your program with unrolled ops and optimised stack handling and lexicals variable types. In other words, this backend is somewhat a "real" compiler in the sense that many people think about compilers. Note however that, currently, it is a very poor compiler in that although it generates (mostly, or at least sometimes) correct code, it performs relatively few optimisations. This will change as the compiler and the types develops. The result is that running an executable compiled with this backend may start up more quickly than running the original Perl program (a feature shared by the C compiler backend--see B::C) and may also execute slightly faster. This is by no means a good optimising compiler--yet.OPTIONSIf there are any non-option arguments, they are taken to be names of objects to be saved (probably doesn't work properly yet). Without extra arguments, it saves the main program.
NOTABLE FUNCTIONScc_queueCreates a new ccpp optree.Initialised by saveoptree_callback in B::C, replaces B::C::walk_and_save_optree. Called by every "CV::save" if ROOT. blocksort also creates its block closure with cc_queue. save_or_restore_lexical_stateThe compiler tracks state of lexical variables in @pad to generate optimised code. But multiple execution paths lead to the entry point of a basic block. The state of the first execution path is saved and all other execution paths are restored to the state of the first one.Missing flags are regenerated by loading values. Added flags must are removed; otherwise the compiler would be too optimistic, hence generating code which doesn't match state of the other execution paths. load_padLoad pad takes (the elements of) a PADLIST as arguments and loads up @pad with Stackobj-derived objects which represent those lexicals.If/when perl itself can generate type information "(my int $foo; my $foo : int)" then we'll take advantage of that here. Until then, we'll use the "-fno-name-magic" in -fname-magic hack to tell the compiler when we want a lexical to be a particular type or to be a register. labelWe not only mark named labels in C as such - with prefix "label_".We also have to mark each known (back jumps) and yet unknown branch targets (forward jumps) for compile-time generated branch points, with the "lab_" prefix. EXAMPLESperl -MO=CC,-O2,-ofoo.c foo.pl perl cc_harness -o foo foo.c Note that "cc_harness" lives in the "B" subdirectory of your perl library directory. The utility called "perlcc" may also be used to help make use of this compiler. # create a shared XS module perl -MO=CC,-mFoo,-oFoo.c Foo.pm perl cc_harness -shared -c -o Foo.so Foo.c # side-effects just for the types and attributes perl -MB::CC -e'my int $i:unsigned; ...' TYPESImplemented type classes are int and num. Planned is str also. Implemented are only SCALAR types yet. Typed arrays and hashes and perfect hashes need coretypes, types and proper "const" support first.Deprecated are inferred types via the names of locals, with '_i', '_d' suffix and an optional 'r' suffix for register allocation. C<my ($i_i, $j_ir, $num_d);> Planned type attributes are int, num, str, unsigned, ro / const. The attributes are perl attributes, and "int|num|str" are either compiler classes or hints for more allowed types. C<my int $i :num;> declares a NV with SVf_IOK. Same as C<my $i:int:double;> C<my int $i;> declares an IV. Same as C<my $i:int;> C<my int $i :str;> declares a PVIV. Same as C<my $i:int:string;> C<my int @array :unsigned = (0..4);> will be used as c var in faster arithmetic and cmp. With :const or :ro even more. C<my str %hash :const = (foo => 'foo', bar => 'bar');> declare string values, generate as read-only perfect hash. :unsigned is valid for int only and declares an UV. :register denotes optionally a short and hot life-time. :temporary are usually generated internally, nameless lexicals. They are more aggressivly destroyed and ignored. :ro or :const throw a compile-time error on write access and may optimize the internal structure of the variable. We don't need to write back the variable to perl (lexical write_back). STATUS OK (classes only): my int $i; my num $d; NOT YET OK (attributes): my int $i :register; my $i :int; my $const :int:const; my $uv :int:unsigned; ISSUES This does not work with pure perl, unless you "use B::CC" or "use types" or implement the classes and attribute type stubs in your code, "sub Mypkg::MODIFY_SCALAR_ATTRIBUTES {}" and "sub Mypkg::FETCH_SCALAR_ATTRIBUTES {}". (TODO: empty should be enough to be detected by the compiler.) Compiled code pulls in the magic MODIFY_SCALAR_ATTRIBUTES and FETCH_SCALAR_ATTRIBUTES functions, even if they are used at compile time only. Using attributes adds an import block to your code. Up until 5.20 only our variable attributes are checked at compile-time, my variables attributes at run-time only, which is too late for the compiler. Perl attributes need to be fixed for types hints by adding "CHECK_SCALAR_ATTRIBUTES". FUTURE We should be able to support types on ARRAY and HASH. For arrays also sizes to omit bounds-checking. my int @array; # array of ints, faster magic-less access esp. in inlined arithmetic and cmp. my str @array : const = qw(foo bar); # compile-time error on write. no lexical write_back my int $hash = {"1" => 1, "2" => 2}; # int values, type-checked on write my str %hash1 : const = (foo => 'bar'); # string keys only => maybe gperf # compile-time error on write Typed hash keys are always strings, as array keys are always int. Only the values are typed. We should be also able to add type attributes for functions and methods, i.e. for argument and return types. See types and <http://blogs.perl.org/users/rurban/2011/02/use-types.html> BUGSPlenty. Current status: experimental.DIFFERENCESThese aren't really bugs but they are constructs which are heavily tied to perl's compile-and-go implementation and with which this compiler backend cannot cope.LoopsStandard perl calculates the target of "next", "last", and "redo" at run-time. The compiler calculates the targets at compile-time. For example, the programsub skip_on_odd { next NUMBER if $_[0] % 2 } NUMBER: for ($i = 0; $i < 5; $i++) { skip_on_odd($i); print $i; } produces the output 024 with standard perl but calculates with the compiler the goto label_NUMBER wrong, producing 01234. Context of ".."The context (scalar or array) of the ".." operator determines whether it behaves as a range or a flip/flop. Standard perl delays until runtime the decision of which context it is in but the compiler needs to know the context at compile-time. For example,@a = (4,6,1,0,0,1); sub range { (shift @a)..(shift @a) } print range(); while (@a) { print scalar(range()) } generates the output 456123E0 with standard Perl but gives a run-time warning with compiled Perl. If the option -strict is used it gives a compile-time error. ArithmeticCompiled Perl programs use native C arithmetic much more frequently than standard perl. Operations on large numbers or on boundary cases may produce different behaviour. In doubt B::CC code behaves more like with "use integer".Deprecated featuresFeatures of standard perl such as $[ which have been deprecated in standard perl since Perl5 was released have not been implemented in the optimizing compiler.AUTHORSMalcolm Beattie "MICB at cpan.org" (1996-1998, retired), Vishal Bhatia <vishal at deja.com> I(1999), Gurusamy Sarathy <gsar at cpan.org> I(1998-2001), Reini Urban "perl-compiler at googlegroups.com" I(2008-now), Heinz Knutzen "heinz.knutzen at gmx.de" I(2010) Will Braswell "wbraswell at hush.com" I(2012)
Visit the GSP FreeBSD Man Page Interface. |