develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Optimised lexical assignments / faster macroöps

Thread Previous | Thread Next
From:
Paul "LeoNerd" Evans
Date:
June 8, 2022 11:23
Subject:
Re: Optimised lexical assignments / faster macroöps
Message ID:
20220608122241.7dbbdb6b@shy.leonerd.org.uk
On Tue, 7 Jun 2022 14:46:32 +0100
Dave Mitchell <davem@iabyn.com> wrote:

> In theory the way forward would be to first regularlise OP_CONST to be
> like the GV ops and become a PADOP on threaded builds. I think this
> may be complicated by when pad slots are located for consts - I think
> this is done quite late in the compilation of a sub. If it were done
> earlier (like however GVs are moved to the pad) then perhaps this
> becomes possible.
> 
> Even better might be to eliminate the PADOP type altogether, and just
> make the op_sv field of the SVOP an SV* or PADOFFSET depending on
> whether the build is threaded.

Yes I think all of that sounds like some useful neatenings that can be
performed. It'd be nice to get rid of the weird way OP_CONST works.

> > I therefore wonder whether this part might need to be done first,
> > performing a somewhat more radical overhaul of the op system by
> > tidying up the meaning of op_targ to really mean the "target" (i.e.
> > output destination) of every op, and never to mean the source even
> > in UNOP or SVOP cases. Having done *that*, then an assigning form
> > of OP_CONST could then use both fields in this case.  
> 
> Not sure I understand that proposal.

Perhaps it's mostly covered by your suggestion above.

My observation is that for most ops, the "op_targ" does mean the target
- i.e. the output destination where the result of the op will be
written. But OP_CONST appears to act differently; its op_targ contains
the input source value, which it will read from and push the result to
the (data) stack. Maybe there are other similar ops; or maybe it really
is the only one. But the plan would be to tidy up this op so it's
nicely consistent - op_targ would always be the output then. Having
done that, then a statement like

  $x = 123;

Could be represented by a single OP_CONST having the padix of $x in its
op_targ, and the {SV pointer or pad offset of the constant} in the
other op field:

  OP_CONST [sv=123 into targ=$x]

There'd be no need to do the full 3-node tree of:

  OP_SASSIGN
    OP_PADSV [$x]
    OP_CONST [123]

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

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