Re: [ANN] LPegLJ v.20
- From: Pierre-Yves Gérardy <pygy79@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 1 Jan 2014 02:49:43 +0100
On Wed, Jan 1, 2014 at 12:58 AM, Yichun Zhang (agentzh)
<agentzh@xxxxxxxxx> wrote:
> By using -jv to run your test.lua with the latest LuaJIT 2.1, I see
> some NYI items aborting trace compilation, which may worth optimizing
> (not sure if they are indeed on hot code paths though):
>
> * NYI: bytecode 71 at lpeglj.lua:1024]
> use of VARG bytecode
> * NYI: bytecode 72 at lpeglj.lua:791
> use of ISNEXT bytecode (we're going to sponsor Mike Pall to address
> this item in LuaJIT)
> * NYI: bytecode 51 at test.lua:333]
> use of FNEW bytecode (we're also going to sponsor Mike for this)
> * NYI: bytecode 50
> use of UCLO bytecode (also for closure creation, ditto)
`VARG` and `ISNEXT` are necessary to reproduce the LPeg semantics.
`LPeg.match()` is a vararg in, vararg out function, and `next()` is
necessary to get the grammar rules, which are stored in a table.
`unpack()` is also necessary to return the captures (or pass them to the
Cmt callbacks).
The closure creations could be avoided with some refactoring (assuming
you're talking about these:
https://github.com/sacek/LPegLJ/blob/master/src/lpvm.lua#L184). You'd
have to store most of the VM state in a FFI struct, and pass it as an
argument, rather than relying on upvalues.
-- Pierre-Yves
Other related posts:
