develooper Front page | perl.perl5.porters | Postings from August 2011

Re: [perl #95986] [PATCH] Superficial separation of INSTRUCTION fromOP.

Thread Previous | Thread Next
From:
Gerard Goossen
Date:
August 3, 2011 05:11
Subject:
Re: [perl #95986] [PATCH] Superficial separation of INSTRUCTION fromOP.
Message ID:
20110803121138.GD6094@ggoossen.net
On Mon, Aug 01, 2011 at 08:32:30AM -0700, Dave Mitchell via RT wrote:
> On Sun, Jul 31, 2011 at 03:58:17AM -0700, Gerard Goossen wrote:
> > Preparation for having INSTRUCTION which is different from OP.
> > This patch only introduces the INSTRUCTION type which is a synonym for
> > OP, changes function and variable definitions to use the type and
> > renames variables from *op to *instr.
> 
> This patch changes function signatures which are part of the public API,
> so needs to be treated with caution.
> 
> To put it in it's wider context, can you provide a link to a thread or
> website which describes your overall plan in more detail?
 
The original proposal:
http://news.perlfoundation.org/2009/08/2009q3-grant-proposal-changing.html
The report:
http://news.perlfoundation.org/2010/04/grant-report-changing-the-perl.html

The lastest version can be found at git://github.com/ggoossen/perl.git
in the codegen-instruction branch (it has some minor problems from
rebasing on the latest blead).

> In particular, I would be keen to see something that explains, in a level
> of detail similar to the following, how your proposed system would operate
> at compile- and run-time.
> 
> Presently:
> 
>     at compile time:
> 	perly,y calls various newFOO() functions when tokens are reduced;
> 	    these functions build a tree of OP structures; and may call
> 	    the ck_foo() functions.
> 	At various times during the building of this tree, top-down calls
> 	    are made to impose context, lvalueness etc, and to gradually
> 	    build a chain of linked op_next's which define the execution
> 	    order.
> 	Finally the peephole optimiser runs through the ops in op_next
> 	    order.
> 	The op tree is usually then embedded in a CV.
> 
>     at run time:
> 	starting with the start op from the CV, the function in the
> 	op_ppaddr field of the OP is called. This function is responsible
> 	for returning the next op, whose op_ppaddr is called, and so on
> 	until a null OP is returned.
> 
> 
> Under your system....?
 
In short:

  at compile time:
    The building of the op_next chain is gone.
    A final walk is done through the optree in finalize_optree doing
        required checking now done by the peephole optimizer. This
        step has already been added to blead.

  before the first run time:
    The code generation does a walk through the optree generating a
        list of instruction, these instruction correspond more or less
        with the current op_next chain
    
  at run time:
    Starting with the first instruction from the CV the function from
        the instr_ppaddr field is called. The function is responsible
        for returning the next instruction, until a NULL instruction is
        returned.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About