Re: LPeg - new version

[Mike Pall <mikelu-0703@...>]

Hi,

Philippe Lhoste wrote:
> So I went ahead and created my own opcodes, reusing most of Roberto's 
> ideas and creating new codes to make some common expressions optimal.

Since a PEG implementation leads naturally to a bytecode
interpreter, you might want to check the literature on optimizing
interpreters first. A good starting point is [Ert02] at:
  http://www.complang.tuwien.ac.at/papers/

> I have current around 25 opcodes [...]

Umm ... IMHO it's much simpler to start with a few basic opcodes.
In the next step don't guess, but do some profiling on realistic
examples. Only then try combining opcodes (superinstructions).
And don't forget that efficient dispatch is as important as
opcode selection.

[ Umm, in case you ever want to write a JIT compiler for it: it's
much simpler if you have only very simple opcodes. Folding in
some tests is ok, but grouping arbitrary opcodes will make things
more difficult later on. ]

> others: my OP_CHARS can handle one or two chars, at the cost of 
> comparison of a flag to 0.

That doesn't look cheap. The main goal when designing for modern
CPUs should be to reduce the number of branches (in particular
unpredictable branches) and cache misses to a minimum. Anything
else will pale in comparison. An unpredictable branch has a
penalty of 10-30 cycles, about as much as a division. A cache
miss may take anything from 10 to 1000s of cycles.

Bye,
     Mike