10 Commits (7134b09e502ca2ff17b165e72b04e88f7973fbab)

Author SHA1 Message Date
David Majda 7134b09e50 Merge |allocateRegisters| and |computeParams| passes
The purpose of this change is to avoid the need to index register
variables storing match results of sequences whose elements are labeled.
The indexing happened when match results of labeled elements were passed
to action/predicate functions.

In order to avoid indexing, the register allocator needs to ensure that
registers storing match results of any labeled sequence elements are
still "alive" after finishing parsing of the sequence. They should not
be used to store anything else at least until code of all actions and
predicates that can see the labels is executed. This requires that the
|allocateRegisters| pass has the knowledge of scoping. Because that
knowledge was already implicitly embedded in the |coputeParams| pass,
the logical step to prevent duplication was to merge it with the
|allocateRegisters| pass. This is what this commit does.

As a part of the merge the tests of both passes were largely refactored.
This is both to accomodate the merge and to make the tests in sync with
the code again (the tests became a bit out-of-sync during the last few
commits -- they tested more than was needed).

The speed/size impact is slightly positive:

Speed impact
------------
Before:     849.86 kB/s
After:      858.16 kB/s
Difference: 0.97%

Size impact
-----------
Before:     876618 b
After:      875602 b
Difference: -0.12%

(Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
12 years ago
David Majda a1fd6acc92 Do not compute |resultIndex| for "rule" nodes
Computing |resultIndex| for their expressions is enough.
12 years ago
David Majda 2d36ebeb59 Mental model change: Variables do not form a stack, they are registers
This commit changes the model underlying parser variables used to store
match results and parse positions. Until now they were treated as a
stack, now they are thought of as registers. The actual behavior does
not change (yet), only the terminology.

More specifically, this commit:

  * Changes parser variable names from |result0|, |result1|, etc. to
    |r0|, |r1|, etc.

  * Changes various internal names and comments to match the new model.

  * Renames the |computeVarIndices| pass to |allocateRegisters|.
12 years ago
David Majda 2f3dd951e9 Do not store result variable indices, just the counts 12 years ago
David Majda 42d4fc6dd4 Get rid of two parser variable stacks
One stack is conceptually simpler, requires less code and will make a
transition to a register-based machine easier.

Note that the stack variables are now named a bit incorrectly
(|result0|, |result1|, etc. even when they store also parse positions).
I didn't bother with renaming because a transition to a register-based
machine will follow soon and the names will change anyway.

The speed/size impact is insignificant.

Speed impact
------------
Before:     839.05 kB/s
After:      839.67 kB/s
Difference: 0.07%

Size impact
-----------
Before:     949783 b
After:      961578 b
Difference: 1.24%

(Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
12 years ago
David Majda 2c8b323ade Replace variable name computations by computations of indices
This commit replaces all variable name computations in |computeVarNames|
and |computeParams| passes by computations of indices. The actual names
are computed later in the |generateCode| pass.

This change makes the code generator the only place that deals with the
actual variable names, making them easier to change for example.

The code generator code seems bit more complicated after the change, but
this complexity will pay off (and mostly disappear) later.
12 years ago
David Majda 725927e05f Change ordering of "action" code
Places all code that does something with "action" AST nodes under code
handling "choice" nodes.

This ordering is logical because now all the node handling code matches
the sequence in which various node types usually appear when descending
through the AST tree.
12 years ago
David Majda cdf23e0a49 Change ordering of "literal", "class" and "any" code
Changes all code that does something with "literal", "class" or "any"
AST nodes so that the code deals with these in the follwing order:

  1. literal
  2. class
  3. any

Previously the code used this ordering:

  1. literal
  2. any
  3. class

The new ordering is more logical because the nodes are handled from the
most specific to the most generic.
12 years ago
David Majda eb4badab24 Refactor named rules AST representation
PEG.js grammar rules are represented by |rule| nodes in the AST. Until
now, all such nodes had a |displayName| property which was either |null|
or stored rule's human-readable name. This commit gets rid of the
|displayName| property and starts representing rules with a
human-readable name using a new |named| node (a child of the |rule|
node).

This change simplifies code generation code a bit as tests for
|displayName| can be removed (see changes in generate-code.js). It also
separates different concerns from each other nicely.
12 years ago
David Majda 4f86fca3d7 Make the code emitter a compiler pass
This gives the compiler a more regular structure.
12 years ago