view release on metacpan or  search on metacpan

README.alpha  view on Meta::CPAN

for using as C libraries (e.g. Foo.a or Foo.so). As the Foo.so files (or
your platform's version) aren't suitable for linking against, you will
have to reget the extension source and rebuild it as a static extension
to force the generation of a suitable Foo.a file. Then you need to make
a symlink (or copy or rename) of that file into a libFoo.a suitable for
cc linking. Then add the appropriate -L and -l options to your
"perl cc_harness" command line to find and link against those libraries.
You may also need to fix up some platform-dependent environment variable
to ensure that linked-against .so files are found at runtime too.

DIFFERENCES

The result of running a compiled Perl program can sometimes be different
from running the same program with standard perl. Think of the compiler
as having a slightly different implementation of the language Perl.
Unfortunately, since Perl has had a single implementation until now,
there are no formal standards or documents defining what behaviour is
guaranteed of Perl the language and what just "happens to work".
Some of the differences below are almost impossible to change because of
the way the compiler works. Others can be changed to produce "standard"
perl behaviour if it's deemed proper and the resulting performance hit
is accepted. I'll use "standard perl" to mean the result of running a
Perl program using the perl executable from the perl distribution.
I'll use "compiled Perl program" to mean running an executable produced
by this compiler kit ("the compiler") with the CC backend.

Loops
    Standard perl calculates the target of "next", "last", and "redo"
    at run-time. The compiler calculates the targets at compile-time.
    For example, the program

        sub 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 gives a compile-time error with the compiler.

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 compile-time error with compiled Perl.

Arithmetic
    Compiled Perl programs use native C arithemtic much more frequently
    than standard perl. Operations on large numbers or on boundary
    cases may produce different behaviour.

Deprecated features
    Features of standard perl such as $[ which have been deprecated
    in standard perl since version 5 was released have not been
    implemented in the compiler.

Others
    I'll add to this list as I remember what they are.

BUGS

Here are some things which may cause the compiler problems.

The following render the compiler useless (without serious hacking):
* Use of the DATA filehandle (via __END__ or __DATA__ tokens)
* Operator overloading with %OVERLOAD
* The (deprecated) magic array-offset variable $[ does not work
* The following operators are not yet implemented for CC
    goto
    sort with a non-default comparison (i.e. a named sub or inline block)
* You can't use "last" to exit from a non-loop block.

The following may give significant problems:
* BEGIN blocks containing complex initialisation code
* Code which is only ever referred to at runtime (e.g. via eval "..." or
  via method calls): see the -u option for the C and CC backends.
* Run-time lookups of lexical variables in "outside" closures

The following may cause problems (not thoroughly tested):
* Dependencies on whether values of some "magic" Perl variables are
  determined at compile-time or runtime.
* For the C and CC backends: compile-time strings which are longer than
  your C compiler can cope with in a single line or definition.
* Reliance on intimate details of global destruction
* For the Bytecode backend: high -On optimisation numbers with code
  that has complex flow of control.
* Any "-w" option in the first line of your perl program is seen and
  acted on by perl itself before the compiler starts. The compiler
  itself then runs with warnings turned on. This may cause perl to
  print out warnings about the compiler itself since I haven't tested
  it thoroughly with warnings turned on.

There is a terser but more complete list in the Todo file.

Malcolm Beattie
2 September 1996