diff options
author | Simon Cozens <simon@netthink.co.uk> | 2001-08-25 18:45:09 +0100 |
---|---|---|
committer | Artur Bergman <sky@nanisky.com> | 2001-08-27 13:18:45 +0000 |
commit | 53e06cf030da5eb71c0b61c0690494f3c70e0555 (patch) | |
tree | 304c53c9149e75adb4d834be77c98e238221b8b5 /pod | |
parent | 13137afc7675869b45e226f8338b8d593c7bf6c8 (diff) | |
download | perl-53e06cf030da5eb71c0b61c0690494f3c70e0555.tar.gz |
Custom Ops
Message-ID: <20010825174509.A5752@netthink.co.uk>
I also added a fix to Opcode.pm to quite test cases.
p4raw-id: //depot/perl@11756
Diffstat (limited to 'pod')
-rw-r--r-- | pod/perlguts.pod | 44 |
1 files changed, 44 insertions, 0 deletions
diff --git a/pod/perlguts.pod b/pod/perlguts.pod index 6478efde97..f89d0a4658 100644 --- a/pod/perlguts.pod +++ b/pod/perlguts.pod @@ -2357,6 +2357,50 @@ high character - C<HALF_UPGRADE> is one of those. =back +=head1 Custom Operators + +Custom operator support is a new experimental feature that allows you do +define your own ops. This is primarily to allow the building of +interpreters for other languages in the Perl core, but it also allows +optimizations through the creation of "macro-ops" (ops which perform the +functions of multiple ops which are usually executed together, such as +C<gvsv, gvsv, add>.) Currently, this feature must be enabled with the C +flag C<-DPERL_CUSTOM_OPS>. + +Enabling the feature will create a new op type, C<OP_CUSTOM>. The Perl +core does not "know" anything special about this op type, and so it will +not be involved in any optimizations. This also means that you can +define your custom ops to be any op structure - unary, binary, list and +so on - you like. + +It's important to know what custom operators won't do for you. They +won't let you add new syntax to Perl, directly. They won't even let you +add new keywords, directly. In fact, they won't change the way Perl +compiles a program at all. You have to do those changes yourself, after +Perl has compiled the program. You do this either by manipulating the op +tree using a C<CHECK> block and the C<B::Generate> module, or by adding +a custom peephole optimizer with the C<optimize> module. + +When you do this, you replace ordinary Perl ops with custom ops by +creating ops with the type C<OP_CUSTOM> and the C<pp_addr> of your own +PP function. This should be defined in XS code, and should look like +the PP ops in C<pp_*.c>. You are responsible for ensuring that your op +takes the appropriate number of values from the stack, and you are +responsible for adding stack marks if necessary. + +You should also "register" your op with the Perl interpreter so that it +can produce sensible error and warning messages. Since it is possible to +have multiple custom ops within the one "logical" op type C<OP_CUSTOM>, +Perl uses the value of C<< o->op_ppaddr >> as a key into the +C<PL_custom_op_descs> and C<PL_custom_op_names> hashes. This means you +need to enter a name and description for your op at the appropriate +place in the C<PL_custom_op_names> and C<PL_custom_op_descs> hashes. + +Forthcoming versions of C<B::Generate> (version 1.0 and above) should +directly support the creation of custom ops by name; C<Opcodes::Custom> +will provide functions which make it trivial to "register" custom ops to +the Perl interpreter. + =head1 AUTHORS Until May 1997, this document was maintained by Jeff Okamoto |