joepie91
/
pegjs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
redux
master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '4fe682794d'
${ noResults }
pegjs/lib/parser.js

4961 lines
178 KiB
JavaScript
Raw Normal View History Unescape Escape

UMD parsers: Regenerate lib/parser.js Part of work on #362.
8 years ago
/* eslint-env node, amd */
Fix ESLint errors in lib/parser.js Fix the following errors: 31:9 error "parser" is defined but never used no-unused-vars 406:14 error "expected" is defined but never used no-unused-vars 1304:15 error "s1" is defined but never used no-unused-vars 1386:15 error "s1" is defined but never used no-unused-vars 1442:15 error "s1" is defined but never used no-unused-vars
8 years ago
/* eslint no-unused-vars: 0 */
Move the "Generated by ..." comment out of wrapping functions The wrapping functions are also generated by PEG.js, so the comment should be above them to mark them as such. This shouldn't cause any problems technically.
8 years ago
/*
* Generated by PEG.js 0.9.0.
*
* http://pegjs.org/
*/
UMD parsers: Regenerate lib/parser.js Part of work on #362.
8 years ago
(function(root, factory) {
if (typeof define === "function" && define.amd) {
define([], factory);
} else if (typeof module === "object" && module.exports) {
module.exports = factory();
}
})(this, function() {
Make generated parsers use strict mode * Issue #324 * JSHint complains about two possible strict violations. But are valid uses of `this`, so we suppress the warnings.
9 years ago
"use strict";
s/subclass/peg$subclass/ The |subclass| function is not intended to be used by user code.
11 years ago
function peg$subclass(child, parent) {
Rebuild src/parser.js (forgotten in the previous commit)
12 years ago
function ctor() { this.constructor = child; }
ctor.prototype = parent.prototype;
child.prototype = new ctor();
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Remove info about found string from syntax errors The |found| property wasn't very useful as it mostly contained just one character or |null| (the exception being syntax errors triggered by |error| or |expected|). Similarly, the "but XXX found" part of the error message (based on the |found| property) wasn't much useful and was redundant in presence of location info. For these reasons, this commit removes the |found| property and corresponding part of the error message from syntax errors. It also modifies error location info slightly to cover a range of 0 characters, not 1 character (except when the error is triggered by |error| or |expected|). This corresponds more precisely to the actual situation. Fixes #372.
9 years ago
function peg$SyntaxError(message, expected, location) {
Error handling: Build error message out of |SyntaxError|'s constructor It will be possible to create errors with user-supplied messages soon. The |SyntaxError| class needs to be ready for that. Implements part of #198.
11 years ago
this.message = message;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
this.expected = expected;
Improve location info in syntax errors Replace |line|, |column|, and |offset| properties of |SyntaxError| with the |location| property. It contains an object similar to the one returned by the |location| function available in action code: { start: { offset: 23, line: 5, column: 6 }, end: { offset: 25, line: 5, column: 8 } } For syntax errors produced in the middle of the input, |start| refers to the first unparsed character and |end| refers to the character behind it (meaning the span is 1 character). This corresponds to the portion of the input in the |found| property. For syntax errors produced the end of the input, both |start| and |end| refer to a character past the end of the input (meaning the span is 0 characters). For syntax errors produced by calling |expected| or |error| functions in action code the location info is the same as the |location| function would return.
9 years ago
this.location = location;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
this.name = "SyntaxError";
Add stack trace in engines based on V8. Fixes #331
9 years ago
if (typeof Error.captureStackTrace === "function") {
Error.captureStackTrace(this, peg$SyntaxError);
}
Fix |quote| visibility in generated parsers |quote| is used outside of the |parse| function so it must be defined in more outer scope. Fixes a problem (introduced in e9d8dc8ebaeda081a6617bb261733bf1a18f2152) where construction of some error messages could throw an error.
12 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Mark |parse| and |SyntaxError| as internal identifiers The |parse| function and the |SyntaxError| exception were meant as internal, so let's mark them as such.
10 years ago
peg$subclass(peg$SyntaxError, Error);
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Rewrite handling of optional parameters Instead of testing arguments.length to see whether an optional parameter was passed to a function, compare its value to "undefined". This approach has two advantages: * It is in line with handling of default parameters in ES6. * Optional parameters are actually spelled out in the parameter list. There is also one important disadvantage, namely that it's impossible to pass "undefined" as an optional parameter value. This required a small change in two tests. Additional notes: * Default parameter values are set in assignments immediately after the function header. This reflects the fact that these assignments really belong to the parameter list (which is where they are in ES6). * Parameter values are checked against "void 0" in places where "undefined" can potentially be redefiend.
8 years ago
function peg$parse(input, options) {
options = options !== void 0 ? options : {};
var parser = this,
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
peg$FAILED = {},
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
peg$startRuleFunctions = { Grammar: peg$parseGrammar },
peg$startRuleFunction = peg$parseGrammar,
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c0 = function(initializer, rules) {
Use Codie for code templates This will allow moving some code into the templates later.
13 years ago
return {
type: "grammar",
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
initializer: extractOptional(initializer, 0),
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
rules: extractList(rules, 0),
location: location()
Use Codie for code templates This will allow moving some code into the templates later.
13 years ago
};
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
peg$c1 = function(code) {
return { type: "initializer", code: code, location: location() };
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c2 = "=",
peg$c3 = { type: "literal", value: "=", description: "\"=\"" },
peg$c4 = function(name, displayName, expression) {
Use Codie for code templates This will allow moving some code into the templates later.
13 years ago
return {
type: "rule",
name: name,
Error handling: Make |?| return |null| on unsuccessful match Before this commit, the |?| operator returned an empty string upon unsuccessful match. This commit changes the returned value to |null|. It also updates the PEG.js grammar and the example grammars, which used the value returned by |?| quite often. Returning |null| is possible because it no longer indicates a match failure. I expect that this change will simplify many real-world grammars, as an empty string is almost never desirable as a return value (except some lexer-level rules) and it is often translated into |null| or some other value in action code. Implements part of #198.
11 years ago
expression: displayName !== null
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
? {
type: "named",
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
name: displayName[0],
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
expression: expression,
location: location()
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
}
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
: expression,
location: location()
Use Codie for code templates This will allow moving some code into the templates later.
13 years ago
};
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c5 = "/",
peg$c6 = { type: "literal", value: "/", description: "\"/\"" },
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
peg$c7 = function(head, tail) {
return tail.length > 0
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
? {
type: "choice",
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
alternatives: buildList(head, tail, 3),
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
location: location()
}
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
: head;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c8 = function(expression, code) {
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
return code !== null
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
? {
type: "action",
expression: expression,
code: code[1],
location: location()
}
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
: expression;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
peg$c9 = function(head, tail) {
return tail.length > 0
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
? {
type: "sequence",
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
elements: buildList(head, tail, 1),
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
location: location()
}
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
: head;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c10 = ":",
peg$c11 = { type: "literal", value: ":", description: "\":\"" },
peg$c12 = function(label, expression) {
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
return {
type: "labeled",
label: label,
expression: expression,
location: location()
};
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c13 = function(operator, expression) {
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
return {
type: OPS_TO_PREFIXED_TYPES[operator],
expression: expression,
location: location()
};
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c14 = "$",
peg$c15 = { type: "literal", value: "$", description: "\"$\"" },
peg$c16 = "&",
peg$c17 = { type: "literal", value: "&", description: "\"&\"" },
peg$c18 = "!",
peg$c19 = { type: "literal", value: "!", description: "\"!\"" },
peg$c20 = function(expression, operator) {
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
return {
type: OPS_TO_SUFFIXED_TYPES[operator],
expression: expression,
location: location()
};
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c21 = "?",
peg$c22 = { type: "literal", value: "?", description: "\"?\"" },
peg$c23 = "*",
peg$c24 = { type: "literal", value: "*", description: "\"*\"" },
peg$c25 = "+",
peg$c26 = { type: "literal", value: "+", description: "\"+\"" },
peg$c27 = "(",
peg$c28 = { type: "literal", value: "(", description: "\"(\"" },
peg$c29 = ")",
peg$c30 = { type: "literal", value: ")", description: "\")\"" },
Fix labels leaking to outer scope Labels in expressions like "(a:"a")" or "(a:"a" b:"b" c:"c")" were visible to the outside despite being wrapped in parens. This commit makes them invisible, as they should be. Note this required introduction of a new "group" AST node, whose purpose is purely to provide label scope isolation. This was necessary because "label" and "sequence" nodes don't (and can't!) provide this isolation themselves. Part of a fix of #396.
8 years ago
peg$c31 = function(expression) {
/*
* The purpose of the "group" AST node is just to isolate label scope. We
* don't need to put it around nodes that can't contain any labels or
* nodes that already isolate label scope themselves. This leaves us with
* "labeled" and "sequence".
*/
return expression.type === 'labeled' || expression.type === 'sequence'
? { type: "group", expression: expression }
: expression;
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c32 = function(name) {
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
return { type: "rule_ref", name: name, location: location() };
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c33 = function(operator, code) {
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
return {
type: OPS_TO_SEMANTIC_PREDICATE_TYPES[operator],
code: code,
location: location()
};
PEG.js grammar: Make rules with operators more generic
10 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c34 = { type: "any", description: "any character" },
peg$c35 = { type: "other", description: "whitespace" },
peg$c36 = "\t",
peg$c37 = { type: "literal", value: "\t", description: "\"\\t\"" },
peg$c38 = "\x0B",
Revert "Use literal raw text in error messages" I no longer think that using raw literal texts in error messages is the right thing to do. The main reason is that it couples error messages with details of the grammar such as use of single or double quotes in literals. A better solution is coming in the next commit. This reverts commit 69a0f769fc1e3cd751affce198a8248cda2859c2.
8 years ago
peg$c39 = { type: "literal", value: "\x0B", description: "\"\\x0B\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c40 = "\f",
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c41 = { type: "literal", value: "\f", description: "\"\\x0C\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c42 = " ",
peg$c43 = { type: "literal", value: " ", description: "\" \"" },
peg$c44 = "\xA0",
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c45 = { type: "literal", value: "\xA0", description: "\"\xA0\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c46 = "\uFEFF",
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c47 = { type: "literal", value: "\uFEFF", description: "\"\uFEFF\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c48 = /^[\n\r\u2028\u2029]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c49 = { type: "class", value: "[\\n\\r\\u2028\\u2029]", description: "[\\n\\r\u2028\u2029]" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c50 = { type: "other", description: "end of line" },
peg$c51 = "\n",
peg$c52 = { type: "literal", value: "\n", description: "\"\\n\"" },
peg$c53 = "\r\n",
peg$c54 = { type: "literal", value: "\r\n", description: "\"\\r\\n\"" },
peg$c55 = "\r",
peg$c56 = { type: "literal", value: "\r", description: "\"\\r\"" },
peg$c57 = "\u2028",
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c58 = { type: "literal", value: "\u2028", description: "\"\u2028\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c59 = "\u2029",
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c60 = { type: "literal", value: "\u2029", description: "\"\u2029\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c61 = { type: "other", description: "comment" },
peg$c62 = "/*",
peg$c63 = { type: "literal", value: "/*", description: "\"/*\"" },
peg$c64 = "*/",
peg$c65 = { type: "literal", value: "*/", description: "\"*/\"" },
peg$c66 = "//",
peg$c67 = { type: "literal", value: "//", description: "\"//\"" },
peg$c68 = function(name) { return name; },
peg$c69 = { type: "other", description: "identifier" },
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
peg$c70 = function(head, tail) { return head + tail.join(""); },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c71 = "_",
peg$c72 = { type: "literal", value: "_", description: "\"_\"" },
peg$c73 = "\\",
peg$c74 = { type: "literal", value: "\\", description: "\"\\\\\"" },
peg$c75 = function(sequence) { return sequence; },
peg$c76 = "\u200C",
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c77 = { type: "literal", value: "\u200C", description: "\"\u200C\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c78 = "\u200D",
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c79 = { type: "literal", value: "\u200D", description: "\"\u200D\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c80 = { type: "other", description: "literal" },
peg$c81 = "i",
peg$c82 = { type: "literal", value: "i", description: "\"i\"" },
peg$c83 = function(value, ignoreCase) {
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
return {
type: "literal",
value: value,
ignoreCase: ignoreCase !== null,
location: location()
};
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c84 = { type: "other", description: "string" },
peg$c85 = "\"",
Revert "Use literal raw text in error messages" I no longer think that using raw literal texts in error messages is the right thing to do. The main reason is that it couples error messages with details of the grammar such as use of single or double quotes in literals. A better solution is coming in the next commit. This reverts commit 69a0f769fc1e3cd751affce198a8248cda2859c2.
8 years ago
peg$c86 = { type: "literal", value: "\"", description: "\"\\\"\"" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c87 = function(chars) { return chars.join(""); },
peg$c88 = "'",
peg$c89 = { type: "literal", value: "'", description: "\"'\"" },
peg$c90 = function() { return text(); },
peg$c91 = { type: "other", description: "character class" },
peg$c92 = "[",
peg$c93 = { type: "literal", value: "[", description: "\"[\"" },
peg$c94 = "^",
peg$c95 = { type: "literal", value: "^", description: "\"^\"" },
peg$c96 = "]",
peg$c97 = { type: "literal", value: "]", description: "\"]\"" },
peg$c98 = function(inverted, parts, ignoreCase) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
return {
type: "class",
PEG.js grammar: Fix line continuation handling in character classes Before this commit, line continuations in character classes contributed an empty string to the list of characters and character ranges matched by a class. While this didn't lead to a buggy behavior with the current code generator, the AST was wrong and the problem could have caused bugs later. This commit fixes the problem.
10 years ago
parts: filterEmptyStrings(parts),
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
inverted: inverted !== null,
ignoreCase: ignoreCase !== null,
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
rawText: text(),
location: location()
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
};
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c99 = "-",
peg$c100 = { type: "literal", value: "-", description: "\"-\"" },
peg$c101 = function(begin, end) {
PEG.js grammar: Fix how |rawText| is created Before this commit, the value of the |rawText| property of "class" AST nodes was created in a hackish way from processed input and it didn't always exactly represent the actual input text. This commit changes the code so that the value of the |rawText| property is created using the |text| function. This is a clean way which also resolves the exact representation problem.
10 years ago
if (begin.charCodeAt(0) > end.charCodeAt(0)) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
error(
"Invalid character range: " + text() + "."
);
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: Fix how |rawText| is created Before this commit, the value of the |rawText| property of "class" AST nodes was created in a hackish way from processed input and it didn't always exactly represent the actual input text. This commit changes the code so that the value of the |rawText| property is created using the |text| function. This is a clean way which also resolves the exact representation problem.
10 years ago
return [begin, end];
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c102 = function() { return ""; },
peg$c103 = "0",
peg$c104 = { type: "literal", value: "0", description: "\"0\"" },
peg$c105 = function() { return "\0"; },
peg$c106 = "b",
peg$c107 = { type: "literal", value: "b", description: "\"b\"" },
peg$c108 = function() { return "\b"; },
peg$c109 = "f",
peg$c110 = { type: "literal", value: "f", description: "\"f\"" },
peg$c111 = function() { return "\f"; },
peg$c112 = "n",
peg$c113 = { type: "literal", value: "n", description: "\"n\"" },
peg$c114 = function() { return "\n"; },
peg$c115 = "r",
peg$c116 = { type: "literal", value: "r", description: "\"r\"" },
peg$c117 = function() { return "\r"; },
peg$c118 = "t",
peg$c119 = { type: "literal", value: "t", description: "\"t\"" },
peg$c120 = function() { return "\t"; },
peg$c121 = "v",
peg$c122 = { type: "literal", value: "v", description: "\"v\"" },
peg$c123 = function() { return "\x0B"; },
peg$c124 = "x",
peg$c125 = { type: "literal", value: "x", description: "\"x\"" },
peg$c126 = "u",
peg$c127 = { type: "literal", value: "u", description: "\"u\"" },
peg$c128 = function(digits) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return String.fromCharCode(parseInt(digits, 16));
},
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c129 = /^[0-9]/,
peg$c130 = { type: "class", value: "[0-9]", description: "[0-9]" },
peg$c131 = /^[0-9a-f]/i,
peg$c132 = { type: "class", value: "[0-9a-f]i", description: "[0-9a-f]i" },
peg$c133 = ".",
peg$c134 = { type: "literal", value: ".", description: "\".\"" },
Add location information to AST nodes This will allow to add location information to |GrammarError| exceptions thrown in various passes.
9 years ago
peg$c135 = function() { return { type: "any", location: location() }; },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c136 = { type: "other", description: "code block" },
peg$c137 = "{",
peg$c138 = { type: "literal", value: "{", description: "\"{\"" },
peg$c139 = "}",
peg$c140 = { type: "literal", value: "}", description: "\"}\"" },
peg$c141 = function(code) { return code; },
peg$c142 = /^[{}]/,
peg$c143 = { type: "class", value: "[{}]", description: "[{}]" },
Update character categories in grammars to Unicode 8.0.0
9 years ago
peg$c144 = /^[a-z\xB5\xDF-\xF6\xF8-\xFF\u0101\u0103\u0105\u0107\u0109\u010B\u010D\u010F\u0111\u0113\u0115\u0117\u0119\u011B\u011D\u011F\u0121\u0123\u0125\u0127\u0129\u012B\u012D\u012F\u0131\u0133\u0135\u0137-\u0138\u013A\u013C\u013E\u0140\u0142\u0144\u0146\u0148-\u0149\u014B\u014D\u014F\u0151\u0153\u0155\u0157\u0159\u015B\u015D\u015F\u0161\u0163\u0165\u0167\u0169\u016B\u016D\u016F\u0171\u0173\u0175\u0177\u017A\u017C\u017E-\u0180\u0183\u0185\u0188\u018C-\u018D\u0192\u0195\u0199-\u019B\u019E\u01A1\u01A3\u01A5\u01A8\u01AA-\u01AB\u01AD\u01B0\u01B4\u01B6\u01B9-\u01BA\u01BD-\u01BF\u01C6\u01C9\u01CC\u01CE\u01D0\u01D2\u01D4\u01D6\u01D8\u01DA\u01DC-\u01DD\u01DF\u01E1\u01E3\u01E5\u01E7\u01E9\u01EB\u01ED\u01EF-\u01F0\u01F3\u01F5\u01F9\u01FB\u01FD\u01FF\u0201\u0203\u0205\u0207\u0209\u020B\u020D\u020F\u0211\u0213\u0215\u0217\u0219\u021B\u021D\u021F\u0221\u0223\u0225\u0227\u0229\u022B\u022D\u022F\u0231\u0233-\u0239\u023C\u023F-\u0240\u0242\u0247\u0249\u024B\u024D\u024F-\u0293\u0295-\u02AF\u0371\u0373\u0377\u037B-\u037D\u0390\u03AC-\u03CE\u03D0-\u03D1\u03D5-\u03D7\u03D9\u03DB\u03DD\u03DF\u03E1\u03E3\u03E5\u03E7\u03E9\u03EB\u03ED\u03EF-\u03F3\u03F5\u03F8\u03FB-\u03FC\u0430-\u045F\u0461\u0463\u0465\u0467\u0469\u046B\u046D\u046F\u0471\u0473\u0475\u0477\u0479\u047B\u047D\u047F\u0481\u048B\u048D\u048F\u0491\u0493\u0495\u0497\u0499\u049B\u049D\u049F\u04A1\u04A3\u04A5\u04A7\u04A9\u04AB\u04AD\u04AF\u04B1\u04B3\u04B5\u04B7\u04B9\u04BB\u04BD\u04BF\u04C2\u04C4\u04C6\u04C8\u04CA\u04CC\u04CE-\u04CF\u04D1\u04D3\u04D5\u04D7\u04D9\u04DB\u04DD\u04DF\u04E1\u04E3\u04E5\u04E7\u04E9\u04EB\u04ED\u04EF\u04F1\u04F3\u04F5\u04F7\u04F9\u04FB\u04FD\u04FF\u0501\u0503\u0505\u0507\u0509\u050B\u050D\u050F\u0511\u0513\u0515\u0517\u0519\u051B\u051D\u051F\u0521\u0523\u0525\u0527\u0529\u052B\u052D\u052F\u0561-\u0587\u13F8-\u13FD\u1D00-\u1D2B\u1D6B-\u1D77\u1D79-\u1D9A\u1E01\u1E03\u1E05\u1E07\u1E09\u1E0B\u1E0D\u1E0F\u1E11\u1E13\u1E15\u1E17\u1E19\u1E1B\u1E1D\u1E1F\u1E21\u1E23\u1E25\u1E27\u1E29\u1E2B\u1E2D\u1E2F\u1E31\u1E33\u1E35\u1E37\u1E39\u1E3B\u1E3D\u1E3F\u1E41\u1E43\u1E45\u1E47\u1E49\u1E4B\u1E4D\u1E4F\u1E51\u1E53\u1E55\u1E57\u1E59\u1E5B\u1E5D\u1E5F\u1E61\u1E63\u1E65\u1E67\u1E69\u1E6B\u1E6D\u1E6F\u1E71\u1E73\u1E75\u1E77\u1E79\u1E7B\u1E7D\u1E7F\u1E81\u1E83\u1E85\u1E87\u1E89\u1E8B\u1E8D\u1E8F\u1E91\u1E93\u1E95-\u1E9D\u1E9F\u1EA1\u1EA3\u1EA5\u1EA7\u1EA9\u1EAB\u1EAD\u1EAF\u1EB1\u1EB3\u1EB5\u1EB7\u1EB9\u1EBB\u1EBD\u1EBF\u1EC1\u1EC3\u1EC5\u1EC7\u1EC9\u1ECB\u1ECD\u1ECF\u1ED1\u1ED3\u1ED5\u1ED7\u1ED9\u1EDB\u1EDD\u1EDF\u1EE1\u1EE3\u1EE5\u1EE7\u1EE9\u1EEB\u1EED\u1EEF\u1EF1\u1EF3\u1EF5\u1EF7\u1EF9\u1EFB\u1EFD\u1EFF-\u1F07\u1F10-\u1F15\u1F20-\u1F27\u1F30-\u1F37\u1F40-\u1F45\u1F50-\u1F57\u1F60-\u1F67\u1F70-\u1F7D\u1F80-\u1F87\u1F90-\u1F97\u1FA0-\u1FA7\u1FB0-\u1FB4\u1FB6-\u1FB7\u1FBE\u1FC2-\u1FC4\u1FC6-\u1FC7\u1FD0-\u1FD3\u1FD6-\u1FD7\u1FE0-\u1FE7\u1FF2-\u1FF4\u1FF6-\u1FF7\u210A\u210E-\u210F\u2113\u212F\u2134\u2139\u213C-\u213D\u2146-\u2149\u214E\u2184\u2C30-\u2C5E\u2C61\u2C65-\u2C66\u2C68\u2C6A\u2C6C\u2C71\u2C73-\u2C74\u2C76-\u2C7B\u2C81\u2C83\u2C85\u2C87\u2C89\u2C8B\u2C8D\u2C8F\u2C91\u2C93\u2C95\u2C97\u2C99\u2C9B\u2C9D\u2C9F\u2CA1\u2CA3\u2CA5\u2CA7\u2CA9\u2CAB\u2CAD\u2CAF\u2CB1\u2CB3\u2CB5\u2CB7\u2CB9\u2CBB\u2CBD\u2CBF\u2CC1\u2CC3\u2CC5\u2CC7\u2CC9\u2CCB\u2CCD\u2CCF\u2CD1\u2CD3\u2CD5\u2CD7\u2CD9\u2CDB\u2CDD\u2CDF\u2CE1\u2CE3-\u2CE4\u2CEC\u2CEE\u2CF3\u2D00-\u2D25\u2D27\u2D2D\uA641\uA643\uA645\uA647\uA649\uA64B\uA64D\uA64F\uA651\uA653\uA655\uA657\uA659\uA65B\uA65D\uA65F\uA661\uA663\uA665\uA667\uA669\uA66B\uA66D\uA681\uA683\uA685\uA687\uA689\uA68B\uA68D\uA68F\uA691\uA693\uA695\uA697\uA699\uA69B\uA723\uA725\uA727\uA729\uA72B\uA72D\uA72F-\uA731\uA733\uA735\uA737\uA739\uA73B\uA73D\uA73F\uA741\uA743\uA745\uA747\uA749\uA74B\uA74D\uA74F\uA751\uA753\uA755\uA757\uA759\uA75B\uA75D\uA75F\uA761\uA763\uA765\uA767\uA769\uA76B\uA76D\uA76F\uA771-\uA778\uA77A\uA77C\uA77F\uA781\uA783\uA785\uA787\uA78C\uA78E\uA791\uA793-\uA795\uA797\uA799\uA79B\uA79D\uA79F\uA7A1\uA7A3\uA7A5\uA7A7\uA7A9\uA7B5\uA7B7\uA7FA\uAB30-\uAB5A\uAB60-\uAB65\uAB70-\uABBF\uFB00-\uFB06\uFB13-\uFB17\uFF41-\uFF5A]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c145 = { type: "class", value: "[\\u0061-\\u007A\\u00B5\\u00DF-\\u00F6\\u00F8-\\u00FF\\u0101\\u0103\\u0105\\u0107\\u0109\\u010B\\u010D\\u010F\\u0111\\u0113\\u0115\\u0117\\u0119\\u011B\\u011D\\u011F\\u0121\\u0123\\u0125\\u0127\\u0129\\u012B\\u012D\\u012F\\u0131\\u0133\\u0135\\u0137-\\u0138\\u013A\\u013C\\u013E\\u0140\\u0142\\u0144\\u0146\\u0148-\\u0149\\u014B\\u014D\\u014F\\u0151\\u0153\\u0155\\u0157\\u0159\\u015B\\u015D\\u015F\\u0161\\u0163\\u0165\\u0167\\u0169\\u016B\\u016D\\u016F\\u0171\\u0173\\u0175\\u0177\\u017A\\u017C\\u017E-\\u0180\\u0183\\u0185\\u0188\\u018C-\\u018D\\u0192\\u0195\\u0199-\\u019B\\u019E\\u01A1\\u01A3\\u01A5\\u01A8\\u01AA-\\u01AB\\u01AD\\u01B0\\u01B4\\u01B6\\u01B9-\\u01BA\\u01BD-\\u01BF\\u01C6\\u01C9\\u01CC\\u01CE\\u01D0\\u01D2\\u01D4\\u01D6\\u01D8\\u01DA\\u01DC-\\u01DD\\u01DF\\u01E1\\u01E3\\u01E5\\u01E7\\u01E9\\u01EB\\u01ED\\u01EF-\\u01F0\\u01F3\\u01F5\\u01F9\\u01FB\\u01FD\\u01FF\\u0201\\u0203\\u0205\\u0207\\u0209\\u020B\\u020D\\u020F\\u0211\\u0213\\u0215\\u0217\\u0219\\u021B\\u021D\\u021F\\u0221\\u0223\\u0225\\u0227\\u0229\\u022B\\u022D\\u022F\\u0231\\u0233-\\u0239\\u023C\\u023F-\\u0240\\u0242\\u0247\\u0249\\u024B\\u024D\\u024F-\\u0293\\u0295-\\u02AF\\u0371\\u0373\\u0377\\u037B-\\u037D\\u0390\\u03AC-\\u03CE\\u03D0-\\u03D1\\u03D5-\\u03D7\\u03D9\\u03DB\\u03DD\\u03DF\\u03E1\\u03E3\\u03E5\\u03E7\\u03E9\\u03EB\\u03ED\\u03EF-\\u03F3\\u03F5\\u03F8\\u03FB-\\u03FC\\u0430-\\u045F\\u0461\\u0463\\u0465\\u0467\\u0469\\u046B\\u046D\\u046F\\u0471\\u0473\\u0475\\u0477\\u0479\\u047B\\u047D\\u047F\\u0481\\u048B\\u048D\\u048F\\u0491\\u0493\\u0495\\u0497\\u0499\\u049B\\u049D\\u049F\\u04A1\\u04A3\\u04A5\\u04A7\\u04A9\\u04AB\\u04AD\\u04AF\\u04B1\\u04B3\\u04B5\\u04B7\\u04B9\\u04BB\\u04BD\\u04BF\\u04C2\\u04C4\\u04C6\\u04C8\\u04CA\\u04CC\\u04CE-\\u04CF\\u04D1\\u04D3\\u04D5\\u04D7\\u04D9\\u04DB\\u04DD\\u04DF\\u04E1\\u04E3\\u04E5\\u04E7\\u04E9\\u04EB\\u04ED\\u04EF\\u04F1\\u04F3\\u04F5\\u04F7\\u04F9\\u04FB\\u04FD\\u04FF\\u0501\\u0503\\u0505\\u0507\\u0509\\u050B\\u050D\\u050F\\u0511\\u0513\\u0515\\u0517\\u0519\\u051B\\u051D\\u051F\\u0521\\u0523\\u0525\\u0527\\u0529\\u052B\\u052D\\u052F\\u0561-\\u0587\\u13F8-\\u13FD\\u1D00-\\u1D2B\\u1D6B-\\u1D77\\u1D79-\\u1D9A\\u1E01\\u1E03\\u1E05\\u1E07\\u1E09\\u1E0B\\u1E0D\\u1E0F\\u1E11\\u1E13\\u1E15\\u1E17\\u1E19\\u1E1B\\u1E1D\\u1E1F\\u1E21\\u1E23\\u1E25\\u1E27\\u1E29\\u1E2B\\u1E2D\\u1E2F\\u1E31\\u1E33\\u1E35\\u1E37\\u1E39\\u1E3B\\u1E3D\\u1E3F\\u1E41\\u1E43\\u1E45\\u1E47\\u1E49\\u1E4B\\u1E4D\\u1E4F\\u1E51\\u1E53\\u1E55\\u1E57\\u1E59\\u1E5B\\u1E5D\\u1E5F\\u1E61\\u1E63\\u1E65\\u1E67\\u1E69\\u1E6B\\u1E6D\\u1E6F\\u1E71\\u1E73\\u1E75\\u1E77\\u1E79\\u1E7B\\u1E7D\\u1E7F\\u1E81\\u1E83\\u1E85\\u1E87\\u1E89\\u1E8B\\u1E8D\\u1E8F\\u1E91\\u1E93\\u1E95-\\u1E9D\\u1E9F\\u1EA1\\u1EA3\\u1EA5\\u1EA7\\u1EA9\\u1EAB\\u1EAD\\u1EAF\\u1EB1\\u1EB3\\u1EB5\\u1EB7\\u1EB9\\u1EBB\\u1EBD\\u1EBF\\u1EC1\\u1EC3\\u1EC5\\u1EC7\\u1EC9\\u1ECB\\u1ECD\\u1ECF\\u1ED1\\u1ED3\\u1ED5\\u1ED7\\u1ED9\\u1EDB\\u1EDD\\u1EDF\\u1EE1\\u1EE3\\u1EE5\\u1EE7\\u1EE9\\u1EEB\\u1EED\\u1EEF\\u1EF1\\u1EF3\\u1EF5\\u1EF7\\u1EF9\\u1EFB\\u1EFD\\u1EFF-\\u1F07\\u1F10-\\u1F15\\u1F20-\\u1F27\\u1F30-\\u1F37\\u1F40-\\u1F45\\u1F50-\\u1F57\\u1F60-\\u1F67\\u1F70-\\u1F7D\\u1F80-\\u1F87\\u1F90-\\u1F97\\u1FA0-\\u1FA7\\u1FB0-\\u1FB4\\u1FB6-\\u1FB7\\u1FBE\\u1FC2-\\u1FC4\\u1FC6-\\u1FC7\\u1FD0-\\u1FD3\\u1FD6-\\u1FD7\\u1FE0-\\u1FE7\\u1FF2-\\u1FF4\\u1FF6-\\u1FF7\\u210A\\u210E-\\u210F\\u2113\\u212F\\u2134\\u2139\\u213C-\\u213D\\u2146-\\u2149\\u214E\\u2184\\u2C30-\\u2C5E\\u2C61\\u2C65-\\u2C66\\u2C68\\u2C6A\\u2C6C\\u2C71\\u2C73-\\u2C74\\u2C76-\\u2C7B\\u2C81\\u2C83\\u2C85\\u2C87\\u2C89\\u2C8B\\u2C8D\\u2C8F\\u2C91\\u2C93\\u2C95\\u2C97\\u2C99\\u2C9B\\u2C9D\\u2C9F\\u2CA1\\u2CA3\\u2CA5\\u2CA7\\u2CA9\\u2CAB\\u2CAD\\u2CAF\\u2CB1\\u2CB3\\u2CB5\\u2CB7\\u2CB9\\u2CBB\\u2CBD\\u2CBF\\u2CC1\\u2CC3\\u2CC5\\u2CC7\\u2CC9\\u2CCB\\u2CCD\\u2CCF\\u2CD1\\u2CD3\\u2CD5\\u2CD7\\u2CD9\\u2CDB\\u2CDD\\u2CDF\\u2CE1\\u2CE3-\\u2CE4\\u2CEC\\u2CEE\\u2CF3\\u2D00-\\u2D25\\u2D27\\u2D2D\\uA641\\uA643\\uA645\\uA647\\uA649\\uA64B\\uA64D\\uA64F\\uA651\\uA653\\uA655\\uA657\\uA659\\uA65B\\uA65D\\uA65F\\uA661
Update character categories in grammars to Unicode 8.0.0
9 years ago
peg$c146 = /^[\u02B0-\u02C1\u02C6-\u02D1\u02E0-\u02E4\u02EC\u02EE\u0374\u037A\u0559\u0640\u06E5-\u06E6\u07F4-\u07F5\u07FA\u081A\u0824\u0828\u0971\u0E46\u0EC6\u10FC\u17D7\u1843\u1AA7\u1C78-\u1C7D\u1D2C-\u1D6A\u1D78\u1D9B-\u1DBF\u2071\u207F\u2090-\u209C\u2C7C-\u2C7D\u2D6F\u2E2F\u3005\u3031-\u3035\u303B\u309D-\u309E\u30FC-\u30FE\uA015\uA4F8-\uA4FD\uA60C\uA67F\uA69C-\uA69D\uA717-\uA71F\uA770\uA788\uA7F8-\uA7F9\uA9CF\uA9E6\uAA70\uAADD\uAAF3-\uAAF4\uAB5C-\uAB5F\uFF70\uFF9E-\uFF9F]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c147 = { type: "class", value: "[\\u02B0-\\u02C1\\u02C6-\\u02D1\\u02E0-\\u02E4\\u02EC\\u02EE\\u0374\\u037A\\u0559\\u0640\\u06E5-\\u06E6\\u07F4-\\u07F5\\u07FA\\u081A\\u0824\\u0828\\u0971\\u0E46\\u0EC6\\u10FC\\u17D7\\u1843\\u1AA7\\u1C78-\\u1C7D\\u1D2C-\\u1D6A\\u1D78\\u1D9B-\\u1DBF\\u2071\\u207F\\u2090-\\u209C\\u2C7C-\\u2C7D\\u2D6F\\u2E2F\\u3005\\u3031-\\u3035\\u303B\\u309D-\\u309E\\u30FC-\\u30FE\\uA015\\uA4F8-\\uA4FD\\uA60C\\uA67F\\uA69C-\\uA69D\\uA717-\\uA71F\\uA770\\uA788\\uA7F8-\\uA7F9\\uA9CF\\uA9E6\\uAA70\\uAADD\\uAAF3-\\uAAF4\\uAB5C-\\uAB5F\\uFF70\\uFF9E-\\uFF9F]", description: "[\u02B0-\u02C1\u02C6-\u02D1\u02E0-\u02E4\u02EC\u02EE\u0374\u037A\u0559\u0640\u06E5-\u06E6\u07F4-\u07F5\u07FA\u081A\u0824\u0828\u0971\u0E46\u0EC6\u10FC\u17D7\u1843\u1AA7\u1C78-\u1C7D\u1D2C-\u1D6A\u1D78\u1D9B-\u1DBF\u2071\u207F\u2090-\u209C\u2C7C-\u2C7D\u2D6F\u2E2F\u3005\u3031-\u3035\u303B\u309D-\u309E\u30FC-\u30FE\uA015\uA4F8-\uA4FD\uA60C\uA67F\uA69C-\uA69D\uA717-\uA71F\uA770\uA788\uA7F8-\uA7F9\uA9CF\uA9E6\uAA70\uAADD\uAAF3-\uAAF4\uAB5C-\uAB5F\uFF70\uFF9E-\uFF9F]" },
Update character categories in grammars to Unicode 8.0.0
9 years ago
peg$c148 = /^[\xAA\xBA\u01BB\u01C0-\u01C3\u0294\u05D0-\u05EA\u05F0-\u05F2\u0620-\u063F\u0641-\u064A\u066E-\u066F\u0671-\u06D3\u06D5\u06EE-\u06EF\u06FA-\u06FC\u06FF\u0710\u0712-\u072F\u074D-\u07A5\u07B1\u07CA-\u07EA\u0800-\u0815\u0840-\u0858\u08A0-\u08B4\u0904-\u0939\u093D\u0950\u0958-\u0961\u0972-\u0980\u0985-\u098C\u098F-\u0990\u0993-\u09A8\u09AA-\u09B0\u09B2\u09B6-\u09B9\u09BD\u09CE\u09DC-\u09DD\u09DF-\u09E1\u09F0-\u09F1\u0A05-\u0A0A\u0A0F-\u0A10\u0A13-\u0A28\u0A2A-\u0A30\u0A32-\u0A33\u0A35-\u0A36\u0A38-\u0A39\u0A59-\u0A5C\u0A5E\u0A72-\u0A74\u0A85-\u0A8D\u0A8F-\u0A91\u0A93-\u0AA8\u0AAA-\u0AB0\u0AB2-\u0AB3\u0AB5-\u0AB9\u0ABD\u0AD0\u0AE0-\u0AE1\u0AF9\u0B05-\u0B0C\u0B0F-\u0B10\u0B13-\u0B28\u0B2A-\u0B30\u0B32-\u0B33\u0B35-\u0B39\u0B3D\u0B5C-\u0B5D\u0B5F-\u0B61\u0B71\u0B83\u0B85-\u0B8A\u0B8E-\u0B90\u0B92-\u0B95\u0B99-\u0B9A\u0B9C\u0B9E-\u0B9F\u0BA3-\u0BA4\u0BA8-\u0BAA\u0BAE-\u0BB9\u0BD0\u0C05-\u0C0C\u0C0E-\u0C10\u0C12-\u0C28\u0C2A-\u0C39\u0C3D\u0C58-\u0C5A\u0C60-\u0C61\u0C85-\u0C8C\u0C8E-\u0C90\u0C92-\u0CA8\u0CAA-\u0CB3\u0CB5-\u0CB9\u0CBD\u0CDE\u0CE0-\u0CE1\u0CF1-\u0CF2\u0D05-\u0D0C\u0D0E-\u0D10\u0D12-\u0D3A\u0D3D\u0D4E\u0D5F-\u0D61\u0D7A-\u0D7F\u0D85-\u0D96\u0D9A-\u0DB1\u0DB3-\u0DBB\u0DBD\u0DC0-\u0DC6\u0E01-\u0E30\u0E32-\u0E33\u0E40-\u0E45\u0E81-\u0E82\u0E84\u0E87-\u0E88\u0E8A\u0E8D\u0E94-\u0E97\u0E99-\u0E9F\u0EA1-\u0EA3\u0EA5\u0EA7\u0EAA-\u0EAB\u0EAD-\u0EB0\u0EB2-\u0EB3\u0EBD\u0EC0-\u0EC4\u0EDC-\u0EDF\u0F00\u0F40-\u0F47\u0F49-\u0F6C\u0F88-\u0F8C\u1000-\u102A\u103F\u1050-\u1055\u105A-\u105D\u1061\u1065-\u1066\u106E-\u1070\u1075-\u1081\u108E\u10D0-\u10FA\u10FD-\u1248\u124A-\u124D\u1250-\u1256\u1258\u125A-\u125D\u1260-\u1288\u128A-\u128D\u1290-\u12B0\u12B2-\u12B5\u12B8-\u12BE\u12C0\u12C2-\u12C5\u12C8-\u12D6\u12D8-\u1310\u1312-\u1315\u1318-\u135A\u1380-\u138F\u1401-\u166C\u166F-\u167F\u1681-\u169A\u16A0-\u16EA\u16F1-\u16F8\u1700-\u170C\u170E-\u1711\u1720-\u1731\u1740-\u1751\u1760-\u176C\u176E-\u1770\u1780-\u17B3\u17DC\u1820-\u1842\u1844-\u1877\u1880-\u18A8\u18AA\u18B0-\u18F5\u1900-\u191E\u1950-\u196D\u1970-\u1974\u1980-\u19AB\u19B0-\u19C9\u1A00-\u1A16\u1A20-\u1A54\u1B05-\u1B33\u1B45-\u1B4B\u1B83-\u1BA0\u1BAE-\u1BAF\u1BBA-\u1BE5\u1C00-\u1C23\u1C4D-\u1C4F\u1C5A-\u1C77\u1CE9-\u1CEC\u1CEE-\u1CF1\u1CF5-\u1CF6\u2135-\u2138\u2D30-\u2D67\u2D80-\u2D96\u2DA0-\u2DA6\u2DA8-\u2DAE\u2DB0-\u2DB6\u2DB8-\u2DBE\u2DC0-\u2DC6\u2DC8-\u2DCE\u2DD0-\u2DD6\u2DD8-\u2DDE\u3006\u303C\u3041-\u3096\u309F\u30A1-\u30FA\u30FF\u3105-\u312D\u3131-\u318E\u31A0-\u31BA\u31F0-\u31FF\u3400-\u4DB5\u4E00-\u9FD5\uA000-\uA014\uA016-\uA48C\uA4D0-\uA4F7\uA500-\uA60B\uA610-\uA61F\uA62A-\uA62B\uA66E\uA6A0-\uA6E5\uA78F\uA7F7\uA7FB-\uA801\uA803-\uA805\uA807-\uA80A\uA80C-\uA822\uA840-\uA873\uA882-\uA8B3\uA8F2-\uA8F7\uA8FB\uA8FD\uA90A-\uA925\uA930-\uA946\uA960-\uA97C\uA984-\uA9B2\uA9E0-\uA9E4\uA9E7-\uA9EF\uA9FA-\uA9FE\uAA00-\uAA28\uAA40-\uAA42\uAA44-\uAA4B\uAA60-\uAA6F\uAA71-\uAA76\uAA7A\uAA7E-\uAAAF\uAAB1\uAAB5-\uAAB6\uAAB9-\uAABD\uAAC0\uAAC2\uAADB-\uAADC\uAAE0-\uAAEA\uAAF2\uAB01-\uAB06\uAB09-\uAB0E\uAB11-\uAB16\uAB20-\uAB26\uAB28-\uAB2E\uABC0-\uABE2\uAC00-\uD7A3\uD7B0-\uD7C6\uD7CB-\uD7FB\uF900-\uFA6D\uFA70-\uFAD9\uFB1D\uFB1F-\uFB28\uFB2A-\uFB36\uFB38-\uFB3C\uFB3E\uFB40-\uFB41\uFB43-\uFB44\uFB46-\uFBB1\uFBD3-\uFD3D\uFD50-\uFD8F\uFD92-\uFDC7\uFDF0-\uFDFB\uFE70-\uFE74\uFE76-\uFEFC\uFF66-\uFF6F\uFF71-\uFF9D\uFFA0-\uFFBE\uFFC2-\uFFC7\uFFCA-\uFFCF\uFFD2-\uFFD7\uFFDA-\uFFDC]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c149 = { type: "class", value: "[\\u00AA\\u00BA\\u01BB\\u01C0-\\u01C3\\u0294\\u05D0-\\u05EA\\u05F0-\\u05F2\\u0620-\\u063F\\u0641-\\u064A\\u066E-\\u066F\\u0671-\\u06D3\\u06D5\\u06EE-\\u06EF\\u06FA-\\u06FC\\u06FF\\u0710\\u0712-\\u072F\\u074D-\\u07A5\\u07B1\\u07CA-\\u07EA\\u0800-\\u0815\\u0840-\\u0858\\u08A0-\\u08B4\\u0904-\\u0939\\u093D\\u0950\\u0958-\\u0961\\u0972-\\u0980\\u0985-\\u098C\\u098F-\\u0990\\u0993-\\u09A8\\u09AA-\\u09B0\\u09B2\\u09B6-\\u09B9\\u09BD\\u09CE\\u09DC-\\u09DD\\u09DF-\\u09E1\\u09F0-\\u09F1\\u0A05-\\u0A0A\\u0A0F-\\u0A10\\u0A13-\\u0A28\\u0A2A-\\u0A30\\u0A32-\\u0A33\\u0A35-\\u0A36\\u0A38-\\u0A39\\u0A59-\\u0A5C\\u0A5E\\u0A72-\\u0A74\\u0A85-\\u0A8D\\u0A8F-\\u0A91\\u0A93-\\u0AA8\\u0AAA-\\u0AB0\\u0AB2-\\u0AB3\\u0AB5-\\u0AB9\\u0ABD\\u0AD0\\u0AE0-\\u0AE1\\u0AF9\\u0B05-\\u0B0C\\u0B0F-\\u0B10\\u0B13-\\u0B28\\u0B2A-\\u0B30\\u0B32-\\u0B33\\u0B35-\\u0B39\\u0B3D\\u0B5C-\\u0B5D\\u0B5F-\\u0B61\\u0B71\\u0B83\\u0B85-\\u0B8A\\u0B8E-\\u0B90\\u0B92-\\u0B95\\u0B99-\\u0B9A\\u0B9C\\u0B9E-\\u0B9F\\u0BA3-\\u0BA4\\u0BA8-\\u0BAA\\u0BAE-\\u0BB9\\u0BD0\\u0C05-\\u0C0C\\u0C0E-\\u0C10\\u0C12-\\u0C28\\u0C2A-\\u0C39\\u0C3D\\u0C58-\\u0C5A\\u0C60-\\u0C61\\u0C85-\\u0C8C\\u0C8E-\\u0C90\\u0C92-\\u0CA8\\u0CAA-\\u0CB3\\u0CB5-\\u0CB9\\u0CBD\\u0CDE\\u0CE0-\\u0CE1\\u0CF1-\\u0CF2\\u0D05-\\u0D0C\\u0D0E-\\u0D10\\u0D12-\\u0D3A\\u0D3D\\u0D4E\\u0D5F-\\u0D61\\u0D7A-\\u0D7F\\u0D85-\\u0D96\\u0D9A-\\u0DB1\\u0DB3-\\u0DBB\\u0DBD\\u0DC0-\\u0DC6\\u0E01-\\u0E30\\u0E32-\\u0E33\\u0E40-\\u0E45\\u0E81-\\u0E82\\u0E84\\u0E87-\\u0E88\\u0E8A\\u0E8D\\u0E94-\\u0E97\\u0E99-\\u0E9F\\u0EA1-\\u0EA3\\u0EA5\\u0EA7\\u0EAA-\\u0EAB\\u0EAD-\\u0EB0\\u0EB2-\\u0EB3\\u0EBD\\u0EC0-\\u0EC4\\u0EDC-\\u0EDF\\u0F00\\u0F40-\\u0F47\\u0F49-\\u0F6C\\u0F88-\\u0F8C\\u1000-\\u102A\\u103F\\u1050-\\u1055\\u105A-\\u105D\\u1061\\u1065-\\u1066\\u106E-\\u1070\\u1075-\\u1081\\u108E\\u10D0-\\u10FA\\u10FD-\\u1248\\u124A-\\u124D\\u1250-\\u1256\\u1258\\u125A-\\u125D\\u1260-\\u1288\\u128A-\\u128D\\u1290-\\u12B0\\u12B2-\\u12B5\\u12B8-\\u12BE\\u12C0\\u12C2-\\u12C5\\u12C8-\\u12D6\\u12D8-\\u1310\\u1312-\\u1315\\u1318-\\u135A\\u1380-\\u138F\\u1401-\\u166C\\u166F-\\u167F\\u1681-\\u169A\\u16A0-\\u16EA\\u16F1-\\u16F8\\u1700-\\u170C\\u170E-\\u1711\\u1720-\\u1731\\u1740-\\u1751\\u1760-\\u176C\\u176E-\\u1770\\u1780-\\u17B3\\u17DC\\u1820-\\u1842\\u1844-\\u1877\\u1880-\\u18A8\\u18AA\\u18B0-\\u18F5\\u1900-\\u191E\\u1950-\\u196D\\u1970-\\u1974\\u1980-\\u19AB\\u19B0-\\u19C9\\u1A00-\\u1A16\\u1A20-\\u1A54\\u1B05-\\u1B33\\u1B45-\\u1B4B\\u1B83-\\u1BA0\\u1BAE-\\u1BAF\\u1BBA-\\u1BE5\\u1C00-\\u1C23\\u1C4D-\\u1C4F\\u1C5A-\\u1C77\\u1CE9-\\u1CEC\\u1CEE-\\u1CF1\\u1CF5-\\u1CF6\\u2135-\\u2138\\u2D30-\\u2D67\\u2D80-\\u2D96\\u2DA0-\\u2DA6\\u2DA8-\\u2DAE\\u2DB0-\\u2DB6\\u2DB8-\\u2DBE\\u2DC0-\\u2DC6\\u2DC8-\\u2DCE\\u2DD0-\\u2DD6\\u2DD8-\\u2DDE\\u3006\\u303C\\u3041-\\u3096\\u309F\\u30A1-\\u30FA\\u30FF\\u3105-\\u312D\\u3131-\\u318E\\u31A0-\\u31BA\\u31F0-\\u31FF\\u3400-\\u4DB5\\u4E00-\\u9FD5\\uA000-\\uA014\\uA016-\\uA48C\\uA4D0-\\uA4F7\\uA500-\\uA60B\\uA610-\\uA61F\\uA62A-\\uA62B\\uA66E\\uA6A0-\\uA6E5\\uA78F\\uA7F7\\uA7FB-\\uA801\\uA803-\\uA805\\uA807-\\uA80A\\uA80C-\\uA822\\uA840-\\uA873\\uA882-\\uA8B3\\uA8F2-\\uA8F7\\uA8FB\\uA8FD\\uA90A-\\uA925\\uA930-\\uA946\\uA960-\\uA97C\\uA984-\\uA9B2\\uA9E0-\\uA9E4\\uA9E7-\\uA9EF\\uA9FA-\\uA9FE\\uAA00-\\uAA28\\uAA40-\\uAA42\\uAA44-\\uAA4B\\uAA60-\\uAA6F\\uAA71-\\uAA76\\uAA7A\\uAA7E-\\uAAAF\\uAAB1\\uAAB5-\\uAAB6\\uAAB9-\\uAABD\\uAAC0\\uAAC2\\uAADB-\\uAADC\\uAAE0-\\uAAEA\\uAAF2\\uAB01-\\uAB06\\uAB09-\\uAB0E\\uAB11-\\uAB16\\uAB20-\\uAB26\\uAB28-\\uAB2E\\uABC0-\\uABE2\\uAC00-\\uD7A3\\uD7B0-\\uD7C6\\uD7CB-\\uD7FB\\uF900-\\uFA6D\\uFA70-\\uFAD9\\uFB1D\\uFB1F-\\uFB28\\uFB2A-\\uFB36\\uFB38-\\uFB3C\\uFB3E\\uFB40-\\uFB41\\uFB43-\\uFB44\\uFB46-\\uFBB1\\uFBD3-\\uFD3D\\uFD50-\\uFD8F\\uFD92-\\uFDC7\\uFDF0-\\uFDFB\\uFE70-\\uFE74\\uFE76-\\uFEFC\\uFF66-\\uFF6F\\uFF71-\\uFF9D\\uFFA0-\\uFFBE\\uFFC2-\\uFFC7\\uFFCA-\\uFFCF\\uFFD2-\\uFFD7\\uFFDA-\\uFFDC]", description: "[\xAA\xBA\u01BB\u01C0-\u01C3\u0294\u05D0-\u05EA\u05F0-\u05F2\u0620-\u063F\u0641-\u064A\u066E-\u066F\u0671-\u06D3\u06D5\u06EE-\u06EF\u06FA-\u06FC\u
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c150 = /^[\u01C5\u01C8\u01CB\u01F2\u1F88-\u1F8F\u1F98-\u1F9F\u1FA8-\u1FAF\u1FBC\u1FCC\u1FFC]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c151 = { type: "class", value: "[\\u01C5\\u01C8\\u01CB\\u01F2\\u1F88-\\u1F8F\\u1F98-\\u1F9F\\u1FA8-\\u1FAF\\u1FBC\\u1FCC\\u1FFC]", description: "[\u01C5\u01C8\u01CB\u01F2\u1F88-\u1F8F\u1F98-\u1F9F\u1FA8-\u1FAF\u1FBC\u1FCC\u1FFC]" },
Update character categories in grammars to Unicode 8.0.0
9 years ago
peg$c152 = /^[A-Z\xC0-\xD6\xD8-\xDE\u0100\u0102\u0104\u0106\u0108\u010A\u010C\u010E\u0110\u0112\u0114\u0116\u0118\u011A\u011C\u011E\u0120\u0122\u0124\u0126\u0128\u012A\u012C\u012E\u0130\u0132\u0134\u0136\u0139\u013B\u013D\u013F\u0141\u0143\u0145\u0147\u014A\u014C\u014E\u0150\u0152\u0154\u0156\u0158\u015A\u015C\u015E\u0160\u0162\u0164\u0166\u0168\u016A\u016C\u016E\u0170\u0172\u0174\u0176\u0178-\u0179\u017B\u017D\u0181-\u0182\u0184\u0186-\u0187\u0189-\u018B\u018E-\u0191\u0193-\u0194\u0196-\u0198\u019C-\u019D\u019F-\u01A0\u01A2\u01A4\u01A6-\u01A7\u01A9\u01AC\u01AE-\u01AF\u01B1-\u01B3\u01B5\u01B7-\u01B8\u01BC\u01C4\u01C7\u01CA\u01CD\u01CF\u01D1\u01D3\u01D5\u01D7\u01D9\u01DB\u01DE\u01E0\u01E2\u01E4\u01E6\u01E8\u01EA\u01EC\u01EE\u01F1\u01F4\u01F6-\u01F8\u01FA\u01FC\u01FE\u0200\u0202\u0204\u0206\u0208\u020A\u020C\u020E\u0210\u0212\u0214\u0216\u0218\u021A\u021C\u021E\u0220\u0222\u0224\u0226\u0228\u022A\u022C\u022E\u0230\u0232\u023A-\u023B\u023D-\u023E\u0241\u0243-\u0246\u0248\u024A\u024C\u024E\u0370\u0372\u0376\u037F\u0386\u0388-\u038A\u038C\u038E-\u038F\u0391-\u03A1\u03A3-\u03AB\u03CF\u03D2-\u03D4\u03D8\u03DA\u03DC\u03DE\u03E0\u03E2\u03E4\u03E6\u03E8\u03EA\u03EC\u03EE\u03F4\u03F7\u03F9-\u03FA\u03FD-\u042F\u0460\u0462\u0464\u0466\u0468\u046A\u046C\u046E\u0470\u0472\u0474\u0476\u0478\u047A\u047C\u047E\u0480\u048A\u048C\u048E\u0490\u0492\u0494\u0496\u0498\u049A\u049C\u049E\u04A0\u04A2\u04A4\u04A6\u04A8\u04AA\u04AC\u04AE\u04B0\u04B2\u04B4\u04B6\u04B8\u04BA\u04BC\u04BE\u04C0-\u04C1\u04C3\u04C5\u04C7\u04C9\u04CB\u04CD\u04D0\u04D2\u04D4\u04D6\u04D8\u04DA\u04DC\u04DE\u04E0\u04E2\u04E4\u04E6\u04E8\u04EA\u04EC\u04EE\u04F0\u04F2\u04F4\u04F6\u04F8\u04FA\u04FC\u04FE\u0500\u0502\u0504\u0506\u0508\u050A\u050C\u050E\u0510\u0512\u0514\u0516\u0518\u051A\u051C\u051E\u0520\u0522\u0524\u0526\u0528\u052A\u052C\u052E\u0531-\u0556\u10A0-\u10C5\u10C7\u10CD\u13A0-\u13F5\u1E00\u1E02\u1E04\u1E06\u1E08\u1E0A\u1E0C\u1E0E\u1E10\u1E12\u1E14\u1E16\u1E18\u1E1A\u1E1C\u1E1E\u1E20\u1E22\u1E24\u1E26\u1E28\u1E2A\u1E2C\u1E2E\u1E30\u1E32\u1E34\u1E36\u1E38\u1E3A\u1E3C\u1E3E\u1E40\u1E42\u1E44\u1E46\u1E48\u1E4A\u1E4C\u1E4E\u1E50\u1E52\u1E54\u1E56\u1E58\u1E5A\u1E5C\u1E5E\u1E60\u1E62\u1E64\u1E66\u1E68\u1E6A\u1E6C\u1E6E\u1E70\u1E72\u1E74\u1E76\u1E78\u1E7A\u1E7C\u1E7E\u1E80\u1E82\u1E84\u1E86\u1E88\u1E8A\u1E8C\u1E8E\u1E90\u1E92\u1E94\u1E9E\u1EA0\u1EA2\u1EA4\u1EA6\u1EA8\u1EAA\u1EAC\u1EAE\u1EB0\u1EB2\u1EB4\u1EB6\u1EB8\u1EBA\u1EBC\u1EBE\u1EC0\u1EC2\u1EC4\u1EC6\u1EC8\u1ECA\u1ECC\u1ECE\u1ED0\u1ED2\u1ED4\u1ED6\u1ED8\u1EDA\u1EDC\u1EDE\u1EE0\u1EE2\u1EE4\u1EE6\u1EE8\u1EEA\u1EEC\u1EEE\u1EF0\u1EF2\u1EF4\u1EF6\u1EF8\u1EFA\u1EFC\u1EFE\u1F08-\u1F0F\u1F18-\u1F1D\u1F28-\u1F2F\u1F38-\u1F3F\u1F48-\u1F4D\u1F59\u1F5B\u1F5D\u1F5F\u1F68-\u1F6F\u1FB8-\u1FBB\u1FC8-\u1FCB\u1FD8-\u1FDB\u1FE8-\u1FEC\u1FF8-\u1FFB\u2102\u2107\u210B-\u210D\u2110-\u2112\u2115\u2119-\u211D\u2124\u2126\u2128\u212A-\u212D\u2130-\u2133\u213E-\u213F\u2145\u2183\u2C00-\u2C2E\u2C60\u2C62-\u2C64\u2C67\u2C69\u2C6B\u2C6D-\u2C70\u2C72\u2C75\u2C7E-\u2C80\u2C82\u2C84\u2C86\u2C88\u2C8A\u2C8C\u2C8E\u2C90\u2C92\u2C94\u2C96\u2C98\u2C9A\u2C9C\u2C9E\u2CA0\u2CA2\u2CA4\u2CA6\u2CA8\u2CAA\u2CAC\u2CAE\u2CB0\u2CB2\u2CB4\u2CB6\u2CB8\u2CBA\u2CBC\u2CBE\u2CC0\u2CC2\u2CC4\u2CC6\u2CC8\u2CCA\u2CCC\u2CCE\u2CD0\u2CD2\u2CD4\u2CD6\u2CD8\u2CDA\u2CDC\u2CDE\u2CE0\u2CE2\u2CEB\u2CED\u2CF2\uA640\uA642\uA644\uA646\uA648\uA64A\uA64C\uA64E\uA650\uA652\uA654\uA656\uA658\uA65A\uA65C\uA65E\uA660\uA662\uA664\uA666\uA668\uA66A\uA66C\uA680\uA682\uA684\uA686\uA688\uA68A\uA68C\uA68E\uA690\uA692\uA694\uA696\uA698\uA69A\uA722\uA724\uA726\uA728\uA72A\uA72C\uA72E\uA732\uA734\uA736\uA738\uA73A\uA73C\uA73E\uA740\uA742\uA744\uA746\uA748\uA74A\uA74C\uA74E\uA750\uA752\uA754\uA756\uA758\uA75A\uA75C\uA75E\uA760\uA762\uA764\uA766\uA768\uA76A\uA76C\uA76E\uA779\uA77B\uA77D-\uA77E\uA780\uA782\uA784\uA786\uA78B\uA78D\uA790\uA792\uA796\uA798\uA79A\uA79C\uA79E\uA7A0\uA7A2\uA7A4\uA7A6\uA7A8\uA7AA-\uA7AD\uA7B0-\uA7B4\uA7B6\uFF21-\uFF3A]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c153 = { type: "class", value: "[\\u0041-\\u005A\\u00C0-\\u00D6\\u00D8-\\u00DE\\u0100\\u0102\\u0104\\u0106\\u0108\\u010A\\u010C\\u010E\\u0110\\u0112\\u0114\\u0116\\u0118\\u011A\\u011C\\u011E\\u0120\\u0122\\u0124\\u0126\\u0128\\u012A\\u012C\\u012E\\u0130\\u0132\\u0134\\u0136\\u0139\\u013B\\u013D\\u013F\\u0141\\u0143\\u0145\\u0147\\u014A\\u014C\\u014E\\u0150\\u0152\\u0154\\u0156\\u0158\\u015A\\u015C\\u015E\\u0160\\u0162\\u0164\\u0166\\u0168\\u016A\\u016C\\u016E\\u0170\\u0172\\u0174\\u0176\\u0178-\\u0179\\u017B\\u017D\\u0181-\\u0182\\u0184\\u0186-\\u0187\\u0189-\\u018B\\u018E-\\u0191\\u0193-\\u0194\\u0196-\\u0198\\u019C-\\u019D\\u019F-\\u01A0\\u01A2\\u01A4\\u01A6-\\u01A7\\u01A9\\u01AC\\u01AE-\\u01AF\\u01B1-\\u01B3\\u01B5\\u01B7-\\u01B8\\u01BC\\u01C4\\u01C7\\u01CA\\u01CD\\u01CF\\u01D1\\u01D3\\u01D5\\u01D7\\u01D9\\u01DB\\u01DE\\u01E0\\u01E2\\u01E4\\u01E6\\u01E8\\u01EA\\u01EC\\u01EE\\u01F1\\u01F4\\u01F6-\\u01F8\\u01FA\\u01FC\\u01FE\\u0200\\u0202\\u0204\\u0206\\u0208\\u020A\\u020C\\u020E\\u0210\\u0212\\u0214\\u0216\\u0218\\u021A\\u021C\\u021E\\u0220\\u0222\\u0224\\u0226\\u0228\\u022A\\u022C\\u022E\\u0230\\u0232\\u023A-\\u023B\\u023D-\\u023E\\u0241\\u0243-\\u0246\\u0248\\u024A\\u024C\\u024E\\u0370\\u0372\\u0376\\u037F\\u0386\\u0388-\\u038A\\u038C\\u038E-\\u038F\\u0391-\\u03A1\\u03A3-\\u03AB\\u03CF\\u03D2-\\u03D4\\u03D8\\u03DA\\u03DC\\u03DE\\u03E0\\u03E2\\u03E4\\u03E6\\u03E8\\u03EA\\u03EC\\u03EE\\u03F4\\u03F7\\u03F9-\\u03FA\\u03FD-\\u042F\\u0460\\u0462\\u0464\\u0466\\u0468\\u046A\\u046C\\u046E\\u0470\\u0472\\u0474\\u0476\\u0478\\u047A\\u047C\\u047E\\u0480\\u048A\\u048C\\u048E\\u0490\\u0492\\u0494\\u0496\\u0498\\u049A\\u049C\\u049E\\u04A0\\u04A2\\u04A4\\u04A6\\u04A8\\u04AA\\u04AC\\u04AE\\u04B0\\u04B2\\u04B4\\u04B6\\u04B8\\u04BA\\u04BC\\u04BE\\u04C0-\\u04C1\\u04C3\\u04C5\\u04C7\\u04C9\\u04CB\\u04CD\\u04D0\\u04D2\\u04D4\\u04D6\\u04D8\\u04DA\\u04DC\\u04DE\\u04E0\\u04E2\\u04E4\\u04E6\\u04E8\\u04EA\\u04EC\\u04EE\\u04F0\\u04F2\\u04F4\\u04F6\\u04F8\\u04FA\\u04FC\\u04FE\\u0500\\u0502\\u0504\\u0506\\u0508\\u050A\\u050C\\u050E\\u0510\\u0512\\u0514\\u0516\\u0518\\u051A\\u051C\\u051E\\u0520\\u0522\\u0524\\u0526\\u0528\\u052A\\u052C\\u052E\\u0531-\\u0556\\u10A0-\\u10C5\\u10C7\\u10CD\\u13A0-\\u13F5\\u1E00\\u1E02\\u1E04\\u1E06\\u1E08\\u1E0A\\u1E0C\\u1E0E\\u1E10\\u1E12\\u1E14\\u1E16\\u1E18\\u1E1A\\u1E1C\\u1E1E\\u1E20\\u1E22\\u1E24\\u1E26\\u1E28\\u1E2A\\u1E2C\\u1E2E\\u1E30\\u1E32\\u1E34\\u1E36\\u1E38\\u1E3A\\u1E3C\\u1E3E\\u1E40\\u1E42\\u1E44\\u1E46\\u1E48\\u1E4A\\u1E4C\\u1E4E\\u1E50\\u1E52\\u1E54\\u1E56\\u1E58\\u1E5A\\u1E5C\\u1E5E\\u1E60\\u1E62\\u1E64\\u1E66\\u1E68\\u1E6A\\u1E6C\\u1E6E\\u1E70\\u1E72\\u1E74\\u1E76\\u1E78\\u1E7A\\u1E7C\\u1E7E\\u1E80\\u1E82\\u1E84\\u1E86\\u1E88\\u1E8A\\u1E8C\\u1E8E\\u1E90\\u1E92\\u1E94\\u1E9E\\u1EA0\\u1EA2\\u1EA4\\u1EA6\\u1EA8\\u1EAA\\u1EAC\\u1EAE\\u1EB0\\u1EB2\\u1EB4\\u1EB6\\u1EB8\\u1EBA\\u1EBC\\u1EBE\\u1EC0\\u1EC2\\u1EC4\\u1EC6\\u1EC8\\u1ECA\\u1ECC\\u1ECE\\u1ED0\\u1ED2\\u1ED4\\u1ED6\\u1ED8\\u1EDA\\u1EDC\\u1EDE\\u1EE0\\u1EE2\\u1EE4\\u1EE6\\u1EE8\\u1EEA\\u1EEC\\u1EEE\\u1EF0\\u1EF2\\u1EF4\\u1EF6\\u1EF8\\u1EFA\\u1EFC\\u1EFE\\u1F08-\\u1F0F\\u1F18-\\u1F1D\\u1F28-\\u1F2F\\u1F38-\\u1F3F\\u1F48-\\u1F4D\\u1F59\\u1F5B\\u1F5D\\u1F5F\\u1F68-\\u1F6F\\u1FB8-\\u1FBB\\u1FC8-\\u1FCB\\u1FD8-\\u1FDB\\u1FE8-\\u1FEC\\u1FF8-\\u1FFB\\u2102\\u2107\\u210B-\\u210D\\u2110-\\u2112\\u2115\\u2119-\\u211D\\u2124\\u2126\\u2128\\u212A-\\u212D\\u2130-\\u2133\\u213E-\\u213F\\u2145\\u2183\\u2C00-\\u2C2E\\u2C60\\u2C62-\\u2C64\\u2C67\\u2C69\\u2C6B\\u2C6D-\\u2C70\\u2C72\\u2C75\\u2C7E-\\u2C80\\u2C82\\u2C84\\u2C86\\u2C88\\u2C8A\\u2C8C\\u2C8E\\u2C90\\u2C92\\u2C94\\u2C96\\u2C98\\u2C9A\\u2C9C\\u2C9E\\u2CA0\\u2CA2\\u2CA4\\u2CA6\\u2CA8\\u2CAA\\u2CAC\\u2CAE\\u2CB0\\u2CB2\\u2CB4\\u2CB6\\u2CB8\\u2CBA\\u2CBC\\u2CBE\\u2CC0\\u2CC2\\u2CC4\\u2CC6\\u2CC8\\u2CCA\\u2CCC\\u2CCE\\u2CD0\\u2CD2\\u2CD4\\u2CD6\\u2CD8\\u2CDA\\u2CDC\\u2CDE\\u2CE0\\u2CE2\\u2CEB\\u2CED\\u2CF2\\uA640\\uA642\\uA644\\uA646\\uA648\\uA64A\\uA64C\\uA64E\\uA650\\uA652\\uA654\\uA656\\uA658\\uA65A\\uA65C\\uA65E\\uA660\\uA662\\uA664\\uA666\\uA668\\uA66A\\uA66C\\uA680\\uA682\\uA684\\uA686\\uA688\
Update character categories in grammars to Unicode 8.0.0
9 years ago
peg$c154 = /^[\u0903\u093B\u093E-\u0940\u0949-\u094C\u094E-\u094F\u0982-\u0983\u09BE-\u09C0\u09C7-\u09C8\u09CB-\u09CC\u09D7\u0A03\u0A3E-\u0A40\u0A83\u0ABE-\u0AC0\u0AC9\u0ACB-\u0ACC\u0B02-\u0B03\u0B3E\u0B40\u0B47-\u0B48\u0B4B-\u0B4C\u0B57\u0BBE-\u0BBF\u0BC1-\u0BC2\u0BC6-\u0BC8\u0BCA-\u0BCC\u0BD7\u0C01-\u0C03\u0C41-\u0C44\u0C82-\u0C83\u0CBE\u0CC0-\u0CC4\u0CC7-\u0CC8\u0CCA-\u0CCB\u0CD5-\u0CD6\u0D02-\u0D03\u0D3E-\u0D40\u0D46-\u0D48\u0D4A-\u0D4C\u0D57\u0D82-\u0D83\u0DCF-\u0DD1\u0DD8-\u0DDF\u0DF2-\u0DF3\u0F3E-\u0F3F\u0F7F\u102B-\u102C\u1031\u1038\u103B-\u103C\u1056-\u1057\u1062-\u1064\u1067-\u106D\u1083-\u1084\u1087-\u108C\u108F\u109A-\u109C\u17B6\u17BE-\u17C5\u17C7-\u17C8\u1923-\u1926\u1929-\u192B\u1930-\u1931\u1933-\u1938\u1A19-\u1A1A\u1A55\u1A57\u1A61\u1A63-\u1A64\u1A6D-\u1A72\u1B04\u1B35\u1B3B\u1B3D-\u1B41\u1B43-\u1B44\u1B82\u1BA1\u1BA6-\u1BA7\u1BAA\u1BE7\u1BEA-\u1BEC\u1BEE\u1BF2-\u1BF3\u1C24-\u1C2B\u1C34-\u1C35\u1CE1\u1CF2-\u1CF3\u302E-\u302F\uA823-\uA824\uA827\uA880-\uA881\uA8B4-\uA8C3\uA952-\uA953\uA983\uA9B4-\uA9B5\uA9BA-\uA9BB\uA9BD-\uA9C0\uAA2F-\uAA30\uAA33-\uAA34\uAA4D\uAA7B\uAA7D\uAAEB\uAAEE-\uAAEF\uAAF5\uABE3-\uABE4\uABE6-\uABE7\uABE9-\uABEA\uABEC]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c155 = { type: "class", value: "[\\u0903\\u093B\\u093E-\\u0940\\u0949-\\u094C\\u094E-\\u094F\\u0982-\\u0983\\u09BE-\\u09C0\\u09C7-\\u09C8\\u09CB-\\u09CC\\u09D7\\u0A03\\u0A3E-\\u0A40\\u0A83\\u0ABE-\\u0AC0\\u0AC9\\u0ACB-\\u0ACC\\u0B02-\\u0B03\\u0B3E\\u0B40\\u0B47-\\u0B48\\u0B4B-\\u0B4C\\u0B57\\u0BBE-\\u0BBF\\u0BC1-\\u0BC2\\u0BC6-\\u0BC8\\u0BCA-\\u0BCC\\u0BD7\\u0C01-\\u0C03\\u0C41-\\u0C44\\u0C82-\\u0C83\\u0CBE\\u0CC0-\\u0CC4\\u0CC7-\\u0CC8\\u0CCA-\\u0CCB\\u0CD5-\\u0CD6\\u0D02-\\u0D03\\u0D3E-\\u0D40\\u0D46-\\u0D48\\u0D4A-\\u0D4C\\u0D57\\u0D82-\\u0D83\\u0DCF-\\u0DD1\\u0DD8-\\u0DDF\\u0DF2-\\u0DF3\\u0F3E-\\u0F3F\\u0F7F\\u102B-\\u102C\\u1031\\u1038\\u103B-\\u103C\\u1056-\\u1057\\u1062-\\u1064\\u1067-\\u106D\\u1083-\\u1084\\u1087-\\u108C\\u108F\\u109A-\\u109C\\u17B6\\u17BE-\\u17C5\\u17C7-\\u17C8\\u1923-\\u1926\\u1929-\\u192B\\u1930-\\u1931\\u1933-\\u1938\\u1A19-\\u1A1A\\u1A55\\u1A57\\u1A61\\u1A63-\\u1A64\\u1A6D-\\u1A72\\u1B04\\u1B35\\u1B3B\\u1B3D-\\u1B41\\u1B43-\\u1B44\\u1B82\\u1BA1\\u1BA6-\\u1BA7\\u1BAA\\u1BE7\\u1BEA-\\u1BEC\\u1BEE\\u1BF2-\\u1BF3\\u1C24-\\u1C2B\\u1C34-\\u1C35\\u1CE1\\u1CF2-\\u1CF3\\u302E-\\u302F\\uA823-\\uA824\\uA827\\uA880-\\uA881\\uA8B4-\\uA8C3\\uA952-\\uA953\\uA983\\uA9B4-\\uA9B5\\uA9BA-\\uA9BB\\uA9BD-\\uA9C0\\uAA2F-\\uAA30\\uAA33-\\uAA34\\uAA4D\\uAA7B\\uAA7D\\uAAEB\\uAAEE-\\uAAEF\\uAAF5\\uABE3-\\uABE4\\uABE6-\\uABE7\\uABE9-\\uABEA\\uABEC]", description: "[\u0903\u093B\u093E-\u0940\u0949-\u094C\u094E-\u094F\u0982-\u0983\u09BE-\u09C0\u09C7-\u09C8\u09CB-\u09CC\u09D7\u0A03\u0A3E-\u0A40\u0A83\u0ABE-\u0AC0\u0AC9\u0ACB-\u0ACC\u0B02-\u0B03\u0B3E\u0B40\u0B47-\u0B48\u0B4B-\u0B4C\u0B57\u0BBE-\u0BBF\u0BC1-\u0BC2\u0BC6-\u0BC8\u0BCA-\u0BCC\u0BD7\u0C01-\u0C03\u0C41-\u0C44\u0C82-\u0C83\u0CBE\u0CC0-\u0CC4\u0CC7-\u0CC8\u0CCA-\u0CCB\u0CD5-\u0CD6\u0D02-\u0D03\u0D3E-\u0D40\u0D46-\u0D48\u0D4A-\u0D4C\u0D57\u0D82-\u0D83\u0DCF-\u0DD1\u0DD8-\u0DDF\u0DF2-\u0DF3\u0F3E-\u0F3F\u0F7F\u102B-\u102C\u1031\u1038\u103B-\u103C\u1056-\u1057\u1062-\u1064\u1067-\u106D\u1083-\u1084\u1087-\u108C\u108F\u109A-\u109C\u17B6\u17BE-\u17C5\u17C7-\u17C8\u1923-\u1926\u1929-\u192B\u1930-\u1931\u1933-\u1938\u1A19-\u1A1A\u1A55\u1A57\u1A61\u1A63-\u1A64\u1A6D-\u1A72\u1B04\u1B35\u1B3B\u1B3D-\u1B41\u1B43-\u1B44\u1B82\u1BA1\u1BA6-\u1BA7\u1BAA\u1BE7\u1BEA-\u1BEC\u1BEE\u1BF2-\u1BF3\u1C24-\u1C2B\u1C34-\u1C35\u1CE1\u1CF2-\u1CF3\u302E-\u302F\uA823-\uA824\uA827\uA880-\uA881\uA8B4-\uA8C3\uA952-\uA953\uA983\uA9B4-\uA9B5\uA9BA-\uA9BB\uA9BD-\uA9C0\uAA2F-\uAA30\uAA33-\uAA34\uAA4D\uAA7B\uAA7D\uAAEB\uAAEE-\uAAEF\uAAF5\uABE3-\uABE4\uABE6-\uABE7\uABE9-\uABEA\uABEC]" },
Update character categories in grammars to Unicode 8.0.0
9 years ago
peg$c156 = /^[\u0300-\u036F\u0483-\u0487\u0591-\u05BD\u05BF\u05C1-\u05C2\u05C4-\u05C5\u05C7\u0610-\u061A\u064B-\u065F\u0670\u06D6-\u06DC\u06DF-\u06E4\u06E7-\u06E8\u06EA-\u06ED\u0711\u0730-\u074A\u07A6-\u07B0\u07EB-\u07F3\u0816-\u0819\u081B-\u0823\u0825-\u0827\u0829-\u082D\u0859-\u085B\u08E3-\u0902\u093A\u093C\u0941-\u0948\u094D\u0951-\u0957\u0962-\u0963\u0981\u09BC\u09C1-\u09C4\u09CD\u09E2-\u09E3\u0A01-\u0A02\u0A3C\u0A41-\u0A42\u0A47-\u0A48\u0A4B-\u0A4D\u0A51\u0A70-\u0A71\u0A75\u0A81-\u0A82\u0ABC\u0AC1-\u0AC5\u0AC7-\u0AC8\u0ACD\u0AE2-\u0AE3\u0B01\u0B3C\u0B3F\u0B41-\u0B44\u0B4D\u0B56\u0B62-\u0B63\u0B82\u0BC0\u0BCD\u0C00\u0C3E-\u0C40\u0C46-\u0C48\u0C4A-\u0C4D\u0C55-\u0C56\u0C62-\u0C63\u0C81\u0CBC\u0CBF\u0CC6\u0CCC-\u0CCD\u0CE2-\u0CE3\u0D01\u0D41-\u0D44\u0D4D\u0D62-\u0D63\u0DCA\u0DD2-\u0DD4\u0DD6\u0E31\u0E34-\u0E3A\u0E47-\u0E4E\u0EB1\u0EB4-\u0EB9\u0EBB-\u0EBC\u0EC8-\u0ECD\u0F18-\u0F19\u0F35\u0F37\u0F39\u0F71-\u0F7E\u0F80-\u0F84\u0F86-\u0F87\u0F8D-\u0F97\u0F99-\u0FBC\u0FC6\u102D-\u1030\u1032-\u1037\u1039-\u103A\u103D-\u103E\u1058-\u1059\u105E-\u1060\u1071-\u1074\u1082\u1085-\u1086\u108D\u109D\u135D-\u135F\u1712-\u1714\u1732-\u1734\u1752-\u1753\u1772-\u1773\u17B4-\u17B5\u17B7-\u17BD\u17C6\u17C9-\u17D3\u17DD\u180B-\u180D\u18A9\u1920-\u1922\u1927-\u1928\u1932\u1939-\u193B\u1A17-\u1A18\u1A1B\u1A56\u1A58-\u1A5E\u1A60\u1A62\u1A65-\u1A6C\u1A73-\u1A7C\u1A7F\u1AB0-\u1ABD\u1B00-\u1B03\u1B34\u1B36-\u1B3A\u1B3C\u1B42\u1B6B-\u1B73\u1B80-\u1B81\u1BA2-\u1BA5\u1BA8-\u1BA9\u1BAB-\u1BAD\u1BE6\u1BE8-\u1BE9\u1BED\u1BEF-\u1BF1\u1C2C-\u1C33\u1C36-\u1C37\u1CD0-\u1CD2\u1CD4-\u1CE0\u1CE2-\u1CE8\u1CED\u1CF4\u1CF8-\u1CF9\u1DC0-\u1DF5\u1DFC-\u1DFF\u20D0-\u20DC\u20E1\u20E5-\u20F0\u2CEF-\u2CF1\u2D7F\u2DE0-\u2DFF\u302A-\u302D\u3099-\u309A\uA66F\uA674-\uA67D\uA69E-\uA69F\uA6F0-\uA6F1\uA802\uA806\uA80B\uA825-\uA826\uA8C4\uA8E0-\uA8F1\uA926-\uA92D\uA947-\uA951\uA980-\uA982\uA9B3\uA9B6-\uA9B9\uA9BC\uA9E5\uAA29-\uAA2E\uAA31-\uAA32\uAA35-\uAA36\uAA43\uAA4C\uAA7C\uAAB0\uAAB2-\uAAB4\uAAB7-\uAAB8\uAABE-\uAABF\uAAC1\uAAEC-\uAAED\uAAF6\uABE5\uABE8\uABED\uFB1E\uFE00-\uFE0F\uFE20-\uFE2F]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c157 = { type: "class", value: "[\\u0300-\\u036F\\u0483-\\u0487\\u0591-\\u05BD\\u05BF\\u05C1-\\u05C2\\u05C4-\\u05C5\\u05C7\\u0610-\\u061A\\u064B-\\u065F\\u0670\\u06D6-\\u06DC\\u06DF-\\u06E4\\u06E7-\\u06E8\\u06EA-\\u06ED\\u0711\\u0730-\\u074A\\u07A6-\\u07B0\\u07EB-\\u07F3\\u0816-\\u0819\\u081B-\\u0823\\u0825-\\u0827\\u0829-\\u082D\\u0859-\\u085B\\u08E3-\\u0902\\u093A\\u093C\\u0941-\\u0948\\u094D\\u0951-\\u0957\\u0962-\\u0963\\u0981\\u09BC\\u09C1-\\u09C4\\u09CD\\u09E2-\\u09E3\\u0A01-\\u0A02\\u0A3C\\u0A41-\\u0A42\\u0A47-\\u0A48\\u0A4B-\\u0A4D\\u0A51\\u0A70-\\u0A71\\u0A75\\u0A81-\\u0A82\\u0ABC\\u0AC1-\\u0AC5\\u0AC7-\\u0AC8\\u0ACD\\u0AE2-\\u0AE3\\u0B01\\u0B3C\\u0B3F\\u0B41-\\u0B44\\u0B4D\\u0B56\\u0B62-\\u0B63\\u0B82\\u0BC0\\u0BCD\\u0C00\\u0C3E-\\u0C40\\u0C46-\\u0C48\\u0C4A-\\u0C4D\\u0C55-\\u0C56\\u0C62-\\u0C63\\u0C81\\u0CBC\\u0CBF\\u0CC6\\u0CCC-\\u0CCD\\u0CE2-\\u0CE3\\u0D01\\u0D41-\\u0D44\\u0D4D\\u0D62-\\u0D63\\u0DCA\\u0DD2-\\u0DD4\\u0DD6\\u0E31\\u0E34-\\u0E3A\\u0E47-\\u0E4E\\u0EB1\\u0EB4-\\u0EB9\\u0EBB-\\u0EBC\\u0EC8-\\u0ECD\\u0F18-\\u0F19\\u0F35\\u0F37\\u0F39\\u0F71-\\u0F7E\\u0F80-\\u0F84\\u0F86-\\u0F87\\u0F8D-\\u0F97\\u0F99-\\u0FBC\\u0FC6\\u102D-\\u1030\\u1032-\\u1037\\u1039-\\u103A\\u103D-\\u103E\\u1058-\\u1059\\u105E-\\u1060\\u1071-\\u1074\\u1082\\u1085-\\u1086\\u108D\\u109D\\u135D-\\u135F\\u1712-\\u1714\\u1732-\\u1734\\u1752-\\u1753\\u1772-\\u1773\\u17B4-\\u17B5\\u17B7-\\u17BD\\u17C6\\u17C9-\\u17D3\\u17DD\\u180B-\\u180D\\u18A9\\u1920-\\u1922\\u1927-\\u1928\\u1932\\u1939-\\u193B\\u1A17-\\u1A18\\u1A1B\\u1A56\\u1A58-\\u1A5E\\u1A60\\u1A62\\u1A65-\\u1A6C\\u1A73-\\u1A7C\\u1A7F\\u1AB0-\\u1ABD\\u1B00-\\u1B03\\u1B34\\u1B36-\\u1B3A\\u1B3C\\u1B42\\u1B6B-\\u1B73\\u1B80-\\u1B81\\u1BA2-\\u1BA5\\u1BA8-\\u1BA9\\u1BAB-\\u1BAD\\u1BE6\\u1BE8-\\u1BE9\\u1BED\\u1BEF-\\u1BF1\\u1C2C-\\u1C33\\u1C36-\\u1C37\\u1CD0-\\u1CD2\\u1CD4-\\u1CE0\\u1CE2-\\u1CE8\\u1CED\\u1CF4\\u1CF8-\\u1CF9\\u1DC0-\\u1DF5\\u1DFC-\\u1DFF\\u20D0-\\u20DC\\u20E1\\u20E5-\\u20F0\\u2CEF-\\u2CF1\\u2D7F\\u2DE0-\\u2DFF\\u302A-\\u302D\\u3099-\\u309A\\uA66F\\uA674-\\uA67D\\uA69E-\\uA69F\\uA6F0-\\uA6F1\\uA802\\uA806\\uA80B\\uA825-\\uA826\\uA8C4\\uA8E0-\\uA8F1\\uA926-\\uA92D\\uA947-\\uA951\\uA980-\\uA982\\uA9B3\\uA9B6-\\uA9B9\\uA9BC\\uA9E5\\uAA29-\\uAA2E\\uAA31-\\uAA32\\uAA35-\\uAA36\\uAA43\\uAA4C\\uAA7C\\uAAB0\\uAAB2-\\uAAB4\\uAAB7-\\uAAB8\\uAABE-\\uAABF\\uAAC1\\uAAEC-\\uAAED\\uAAF6\\uABE5\\uABE8\\uABED\\uFB1E\\uFE00-\\uFE0F\\uFE20-\\uFE2F]", description: "[\u0300-\u036F\u0483-\u0487\u0591-\u05BD\u05BF\u05C1-\u05C2\u05C4-\u05C5\u05C7\u0610-\u061A\u064B-\u065F\u0670\u06D6-\u06DC\u06DF-\u06E4\u06E7-\u06E8\u06EA-\u06ED\u0711\u0730-\u074A\u07A6-\u07B0\u07EB-\u07F3\u0816-\u0819\u081B-\u0823\u0825-\u0827\u0829-\u082D\u0859-\u085B\u08E3-\u0902\u093A\u093C\u0941-\u0948\u094D\u0951-\u0957\u0962-\u0963\u0981\u09BC\u09C1-\u09C4\u09CD\u09E2-\u09E3\u0A01-\u0A02\u0A3C\u0A41-\u0A42\u0A47-\u0A48\u0A4B-\u0A4D\u0A51\u0A70-\u0A71\u0A75\u0A81-\u0A82\u0ABC\u0AC1-\u0AC5\u0AC7-\u0AC8\u0ACD\u0AE2-\u0AE3\u0B01\u0B3C\u0B3F\u0B41-\u0B44\u0B4D\u0B56\u0B62-\u0B63\u0B82\u0BC0\u0BCD\u0C00\u0C3E-\u0C40\u0C46-\u0C48\u0C4A-\u0C4D\u0C55-\u0C56\u0C62-\u0C63\u0C81\u0CBC\u0CBF\u0CC6\u0CCC-\u0CCD\u0CE2-\u0CE3\u0D01\u0D41-\u0D44\u0D4D\u0D62-\u0D63\u0DCA\u0DD2-\u0DD4\u0DD6\u0E31\u0E34-\u0E3A\u0E47-\u0E4E\u0EB1\u0EB4-\u0EB9\u0EBB-\u0EBC\u0EC8-\u0ECD\u0F18-\u0F19\u0F35\u0F37\u0F39\u0F71-\u0F7E\u0F80-\u0F84\u0F86-\u0F87\u0F8D-\u0F97\u0F99-\u0FBC\u0FC6\u102D-\u1030\u1032-\u1037\u1039-\u103A\u103D-\u103E\u1058-\u1059\u105E-\u1060\u1071-\u1074\u1082\u1085-\u1086\u108D\u109D\u135D-\u135F\u1712-\u1714\u1732-\u1734\u1752-\u1753\u1772-\u1773\u17B4-\u17B5\u17B7-\u17BD\u17C6\u17C9-\u17D3\u17DD\u180B-\u180D\u18A9\u1920-\u1922\u1927-\u1928\u1932\u1939-\u193B\u1A17-\u1A18\u1A1B\u1A56\u1A58-\u1A5E\u1A60\u1A62\u1A65-\u1A6C\u1A73-\u1A7C\u1A7F\u1AB0-\u1ABD\u1B00-\u1B03\u1B34\u1B36-\u1B3A\u1B3C\u1B42\u1B6B-\u1B73\u1B80-\u1B81\u1BA2-\u1BA5\u1BA8-\u1BA9\u1BAB-\u1BAD\u1BE6\u1BE8-\u1BE9\u1BED\u1BEF-\u1BF1\u1C2C-\u1C33\u1C36-\u1C37\u1CD0-\u1CD2\u1CD4-\u1CE0\u1CE2-\u1CE8\u1CED\u1CF4\u1CF8-\u1CF9\u1DC0-\u1DF5\u1DFC-\u1DFF\u20D0-\u20DC\u20E
Update character categories in grammars to Unicode 8.0.0
9 years ago
peg$c158 = /^[0-9\u0660-\u0669\u06F0-\u06F9\u07C0-\u07C9\u0966-\u096F\u09E6-\u09EF\u0A66-\u0A6F\u0AE6-\u0AEF\u0B66-\u0B6F\u0BE6-\u0BEF\u0C66-\u0C6F\u0CE6-\u0CEF\u0D66-\u0D6F\u0DE6-\u0DEF\u0E50-\u0E59\u0ED0-\u0ED9\u0F20-\u0F29\u1040-\u1049\u1090-\u1099\u17E0-\u17E9\u1810-\u1819\u1946-\u194F\u19D0-\u19D9\u1A80-\u1A89\u1A90-\u1A99\u1B50-\u1B59\u1BB0-\u1BB9\u1C40-\u1C49\u1C50-\u1C59\uA620-\uA629\uA8D0-\uA8D9\uA900-\uA909\uA9D0-\uA9D9\uA9F0-\uA9F9\uAA50-\uAA59\uABF0-\uABF9\uFF10-\uFF19]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c159 = { type: "class", value: "[\\u0030-\\u0039\\u0660-\\u0669\\u06F0-\\u06F9\\u07C0-\\u07C9\\u0966-\\u096F\\u09E6-\\u09EF\\u0A66-\\u0A6F\\u0AE6-\\u0AEF\\u0B66-\\u0B6F\\u0BE6-\\u0BEF\\u0C66-\\u0C6F\\u0CE6-\\u0CEF\\u0D66-\\u0D6F\\u0DE6-\\u0DEF\\u0E50-\\u0E59\\u0ED0-\\u0ED9\\u0F20-\\u0F29\\u1040-\\u1049\\u1090-\\u1099\\u17E0-\\u17E9\\u1810-\\u1819\\u1946-\\u194F\\u19D0-\\u19D9\\u1A80-\\u1A89\\u1A90-\\u1A99\\u1B50-\\u1B59\\u1BB0-\\u1BB9\\u1C40-\\u1C49\\u1C50-\\u1C59\\uA620-\\uA629\\uA8D0-\\uA8D9\\uA900-\\uA909\\uA9D0-\\uA9D9\\uA9F0-\\uA9F9\\uAA50-\\uAA59\\uABF0-\\uABF9\\uFF10-\\uFF19]", description: "[0-9\u0660-\u0669\u06F0-\u06F9\u07C0-\u07C9\u0966-\u096F\u09E6-\u09EF\u0A66-\u0A6F\u0AE6-\u0AEF\u0B66-\u0B6F\u0BE6-\u0BEF\u0C66-\u0C6F\u0CE6-\u0CEF\u0D66-\u0D6F\u0DE6-\u0DEF\u0E50-\u0E59\u0ED0-\u0ED9\u0F20-\u0F29\u1040-\u1049\u1090-\u1099\u17E0-\u17E9\u1810-\u1819\u1946-\u194F\u19D0-\u19D9\u1A80-\u1A89\u1A90-\u1A99\u1B50-\u1B59\u1BB0-\u1BB9\u1C40-\u1C49\u1C50-\u1C59\uA620-\uA629\uA8D0-\uA8D9\uA900-\uA909\uA9D0-\uA9D9\uA9F0-\uA9F9\uAA50-\uAA59\uABF0-\uABF9\uFF10-\uFF19]" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c160 = /^[\u16EE-\u16F0\u2160-\u2182\u2185-\u2188\u3007\u3021-\u3029\u3038-\u303A\uA6E6-\uA6EF]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c161 = { type: "class", value: "[\\u16EE-\\u16F0\\u2160-\\u2182\\u2185-\\u2188\\u3007\\u3021-\\u3029\\u3038-\\u303A\\uA6E6-\\uA6EF]", description: "[\u16EE-\u16F0\u2160-\u2182\u2185-\u2188\u3007\u3021-\u3029\u3038-\u303A\uA6E6-\uA6EF]" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c162 = /^[_\u203F-\u2040\u2054\uFE33-\uFE34\uFE4D-\uFE4F\uFF3F]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c163 = { type: "class", value: "[\\u005F\\u203F-\\u2040\\u2054\\uFE33-\\uFE34\\uFE4D-\\uFE4F\\uFF3F]", description: "[_\u203F-\u2040\u2054\uFE33-\uFE34\uFE4D-\uFE4F\uFF3F]" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c164 = /^[ \xA0\u1680\u2000-\u200A\u202F\u205F\u3000]/,
Improve expression descriptions in error messages Before this commit, descriptions of literals used in error messages were built by applying JavaScript string escaping to their values, making the descriptions look like JavaScript strings. Descriptions of character classes were built using their raw text. These approaches were mutually inconsistent and lead to descriptions which were over-escaped and not necessarily human-friendly (in case of literals) or coupled with details of the grammar (in case of character classes). This commit changes description building code in both cases and unifies it. The intent is to generate human-friendly descriptions of matched expressions which are clean, unambiguous, and which don't escape too many characters, while handling special characters such as newlines well. Fixes #127.
8 years ago
peg$c165 = { type: "class", value: "[\\u0020\\u00A0\\u1680\\u2000-\\u200A\\u202F\\u205F\\u3000]", description: "[ \xA0\u1680\u2000-\u200A\u202F\u205F\u3000]" },
Regenerate lib/parser.js after bytecode changes
10 years ago
peg$c166 = "break",
peg$c167 = { type: "literal", value: "break", description: "\"break\"" },
peg$c168 = "case",
peg$c169 = { type: "literal", value: "case", description: "\"case\"" },
peg$c170 = "catch",
peg$c171 = { type: "literal", value: "catch", description: "\"catch\"" },
peg$c172 = "class",
peg$c173 = { type: "literal", value: "class", description: "\"class\"" },
peg$c174 = "const",
peg$c175 = { type: "literal", value: "const", description: "\"const\"" },
peg$c176 = "continue",
peg$c177 = { type: "literal", value: "continue", description: "\"continue\"" },
peg$c178 = "debugger",
peg$c179 = { type: "literal", value: "debugger", description: "\"debugger\"" },
peg$c180 = "default",
peg$c181 = { type: "literal", value: "default", description: "\"default\"" },
peg$c182 = "delete",
peg$c183 = { type: "literal", value: "delete", description: "\"delete\"" },
peg$c184 = "do",
peg$c185 = { type: "literal", value: "do", description: "\"do\"" },
peg$c186 = "else",
peg$c187 = { type: "literal", value: "else", description: "\"else\"" },
peg$c188 = "enum",
peg$c189 = { type: "literal", value: "enum", description: "\"enum\"" },
peg$c190 = "export",
peg$c191 = { type: "literal", value: "export", description: "\"export\"" },
peg$c192 = "extends",
peg$c193 = { type: "literal", value: "extends", description: "\"extends\"" },
peg$c194 = "false",
peg$c195 = { type: "literal", value: "false", description: "\"false\"" },
peg$c196 = "finally",
peg$c197 = { type: "literal", value: "finally", description: "\"finally\"" },
peg$c198 = "for",
peg$c199 = { type: "literal", value: "for", description: "\"for\"" },
peg$c200 = "function",
peg$c201 = { type: "literal", value: "function", description: "\"function\"" },
peg$c202 = "if",
peg$c203 = { type: "literal", value: "if", description: "\"if\"" },
peg$c204 = "import",
peg$c205 = { type: "literal", value: "import", description: "\"import\"" },
peg$c206 = "instanceof",
peg$c207 = { type: "literal", value: "instanceof", description: "\"instanceof\"" },
peg$c208 = "in",
peg$c209 = { type: "literal", value: "in", description: "\"in\"" },
peg$c210 = "new",
peg$c211 = { type: "literal", value: "new", description: "\"new\"" },
peg$c212 = "null",
peg$c213 = { type: "literal", value: "null", description: "\"null\"" },
peg$c214 = "return",
peg$c215 = { type: "literal", value: "return", description: "\"return\"" },
peg$c216 = "super",
peg$c217 = { type: "literal", value: "super", description: "\"super\"" },
peg$c218 = "switch",
peg$c219 = { type: "literal", value: "switch", description: "\"switch\"" },
peg$c220 = "this",
peg$c221 = { type: "literal", value: "this", description: "\"this\"" },
peg$c222 = "throw",
peg$c223 = { type: "literal", value: "throw", description: "\"throw\"" },
peg$c224 = "true",
peg$c225 = { type: "literal", value: "true", description: "\"true\"" },
peg$c226 = "try",
peg$c227 = { type: "literal", value: "try", description: "\"try\"" },
peg$c228 = "typeof",
peg$c229 = { type: "literal", value: "typeof", description: "\"typeof\"" },
peg$c230 = "var",
peg$c231 = { type: "literal", value: "var", description: "\"var\"" },
peg$c232 = "void",
peg$c233 = { type: "literal", value: "void", description: "\"void\"" },
peg$c234 = "while",
peg$c235 = { type: "literal", value: "while", description: "\"while\"" },
peg$c236 = "with",
peg$c237 = { type: "literal", value: "with", description: "\"with\"" },
peg$c238 = ";",
peg$c239 = { type: "literal", value: ";", description: "\";\"" },
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = 0,
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = 0,
Remove support for newlines other than "\n" and "\r\n" Before this commit, generated parsers considered the following character sequences as newlines: Sequence Description ------------------------------ "\n" Unix "\r" Old Mac "\r\n" Windows "\u2028" line separator "\u2029" paragraph separator This commit limits the sequences only to "\n" and "\r\n". The reason is that nobody uses Unicode newlines or "\r" in practice. A positive side effect of the change is that newline-handling code became simpler (and likely faster).
8 years ago
peg$posDetailsCache = [{ line: 1, column: 1 }],
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$maxFailPos = 0,
peg$maxFailExpected = [],
peg$silentFails = 0,
peg$result;
if ("startRule" in options) {
if (!(options.startRule in peg$startRuleFunctions)) {
throw new Error("Can't start parsing from rule \"" + options.startRule + "\".");
}
peg$startRuleFunction = peg$startRuleFunctions[options.startRule];
}
function text() {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
return input.substring(peg$savedPos, peg$currPos);
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Improve location info available in action code Replace |line|, |column|, and |offset| functions with the |location| function. It returns an object like this: { start: { offset: 23, line: 5, column: 6 }, end: { offset: 25, line: 5, column: 8 } } In actions, |start| refers to the position at the beginning of action's expression and |end| refers to the position after the end of action's expression. This allows one to easily add location info e.g. to AST nodes created in actions. In predicates, both |start| and |end| refer to the current position. Fixes #246.
9 years ago
function location() {
Improve location info in syntax errors Replace |line|, |column|, and |offset| properties of |SyntaxError| with the |location| property. It contains an object similar to the one returned by the |location| function available in action code: { start: { offset: 23, line: 5, column: 6 }, end: { offset: 25, line: 5, column: 8 } } For syntax errors produced in the middle of the input, |start| refers to the first unparsed character and |end| refers to the character behind it (meaning the span is 1 character). This corresponds to the portion of the input in the |found| property. For syntax errors produced the end of the input, both |start| and |end| refer to a character past the end of the input (meaning the span is 0 characters). For syntax errors produced by calling |expected| or |error| functions in action code the location info is the same as the |location| function would return.
9 years ago
return peg$computeLocation(peg$savedPos, peg$currPos);
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Support passing custom location info to "error" and "expected" Based on a pull request by Konstantin (@YemSalat): https://github.com/pegjs/pegjs/pull/391 Resolves #390.
8 years ago
function expected(description, location) {
location = location !== void 0 ? location : peg$computeLocation(peg$savedPos, peg$currPos)
Refine error handling further Before this commit, the |expected| and |error| functions didn't halt the parsing immediately, but triggered a regular match failure. After they were called, the parser could backtrack, try another branches, and only if no other branch succeeded, it triggered an exception with information possibly based on parameters passed to the |expected| or |error| function (this depended on positions where failures in other branches have occurred). While nice in theory, this solution didn't work well in practice. There were at least two problems: 1. Action expression could have easily triggered a match failure later in the input than the action itself. This resulted in the action-triggered failure to be shadowed by the expression-triggered one. Consider the following example: integer = digits:[0-9]+ { var result = parseInt(digits.join(""), 10); if (result % 2 === 0) { error("The number must be an odd integer."); return; } return result; } Given input "2", the |[0-9]+| expression would record a match failure at position 1 (an unsuccessful attempt to parse yet another digit after "2"). However, a failure triggered by the |error| call would occur at position 0. This problem could have been solved by silencing match failures in action expressions, but that would lead to severe performance problems (yes, I tried and measured). Other possible solutions are hacks which I didn't want to introduce into PEG.js. 2. Triggering a match failure in action code could have lead to unexpected backtracking. Consider the following example: class = "[" (charRange / char)* "]" charRange = begin:char "-" end:char { if (begin.data.charCodeAt(0) > end.data.charCodeAt(0)) { error("Invalid character range: " + begin + "-" + end + "."); } // ... } char = [a-zA-Z0-9_\-] Given input "[b-a]", the |charRange| rule would fail, but the parser would try the |char| rule and succeed repeatedly, resulting in "b-a" being parsed as a sequence of three |char|'s, which it is not. This problem could have been solved by using negative predicates, but that would complicate the grammar and still wouldn't get rid of unintuitive behavior. Given these problems I decided to change the semantics of the |expected| and |error| functions. They don't interact with regular match failure mechanism anymore, but they cause and immediate parse failure by throwing an exception. I think this is more intuitive behavior with less harmful side effects. The disadvantage of the new approach is that one can't backtrack from an action-triggered error. I don't see this as a big deal as I think this will be rarely needed and one can always use a semantic predicate as a workaround. Speed impact ------------ Before: 993.84 kB/s After: 998.05 kB/s Difference: 0.42% Size impact ----------- Before: 1019968 b After: 975434 b Difference: -4.37% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
throw peg$buildException(
null,
[{ type: "other", description: description }],
Support passing custom location info to "error" and "expected" Based on a pull request by Konstantin (@YemSalat): https://github.com/pegjs/pegjs/pull/391 Resolves #390.
8 years ago
location
Refine error handling further Before this commit, the |expected| and |error| functions didn't halt the parsing immediately, but triggered a regular match failure. After they were called, the parser could backtrack, try another branches, and only if no other branch succeeded, it triggered an exception with information possibly based on parameters passed to the |expected| or |error| function (this depended on positions where failures in other branches have occurred). While nice in theory, this solution didn't work well in practice. There were at least two problems: 1. Action expression could have easily triggered a match failure later in the input than the action itself. This resulted in the action-triggered failure to be shadowed by the expression-triggered one. Consider the following example: integer = digits:[0-9]+ { var result = parseInt(digits.join(""), 10); if (result % 2 === 0) { error("The number must be an odd integer."); return; } return result; } Given input "2", the |[0-9]+| expression would record a match failure at position 1 (an unsuccessful attempt to parse yet another digit after "2"). However, a failure triggered by the |error| call would occur at position 0. This problem could have been solved by silencing match failures in action expressions, but that would lead to severe performance problems (yes, I tried and measured). Other possible solutions are hacks which I didn't want to introduce into PEG.js. 2. Triggering a match failure in action code could have lead to unexpected backtracking. Consider the following example: class = "[" (charRange / char)* "]" charRange = begin:char "-" end:char { if (begin.data.charCodeAt(0) > end.data.charCodeAt(0)) { error("Invalid character range: " + begin + "-" + end + "."); } // ... } char = [a-zA-Z0-9_\-] Given input "[b-a]", the |charRange| rule would fail, but the parser would try the |char| rule and succeed repeatedly, resulting in "b-a" being parsed as a sequence of three |char|'s, which it is not. This problem could have been solved by using negative predicates, but that would complicate the grammar and still wouldn't get rid of unintuitive behavior. Given these problems I decided to change the semantics of the |expected| and |error| functions. They don't interact with regular match failure mechanism anymore, but they cause and immediate parse failure by throwing an exception. I think this is more intuitive behavior with less harmful side effects. The disadvantage of the new approach is that one can't backtrack from an action-triggered error. I don't see this as a big deal as I think this will be rarely needed and one can always use a semantic predicate as a workaround. Speed impact ------------ Before: 993.84 kB/s After: 998.05 kB/s Difference: 0.42% Size impact ----------- Before: 1019968 b After: 975434 b Difference: -4.37% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
);
Error handling: Implement the |expected| function The |expected| function allows users to report regular match failures inside actions. If the |expected| function is called, and the reported match failure turns out to be the cause of a parse error, the error message reported by the parser will be in the usual "Expected ... but found ..." format with the description specified in the |expected| call used as part of the message. Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
}
Support passing custom location info to "error" and "expected" Based on a pull request by Konstantin (@YemSalat): https://github.com/pegjs/pegjs/pull/391 Resolves #390.
8 years ago
function error(message, location) {
location = location !== void 0 ? location : peg$computeLocation(peg$savedPos, peg$currPos)
throw peg$buildException(message, null, location);
Error handling: Implement the |error| function The |error| function allows users to report custom match failures inside actions. If the |error| function is called, and the reported match failure turns out to be the cause of a parse error, the error message reported by the parser will be exactly the one specified in the |error| call. Implements part of #198. Speed impact ------------ Before: 999.83 kB/s After: 1000.84 kB/s Difference: 0.10% Size impact ----------- Before: 1017212 b After: 1019968 b Difference: 0.27% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
function peg$computePosDetails(pos) {
Remove support for newlines other than "\n" and "\r\n" Before this commit, generated parsers considered the following character sequences as newlines: Sequence Description ------------------------------ "\n" Unix "\r" Old Mac "\r\n" Windows "\u2028" line separator "\u2029" paragraph separator This commit limits the sequences only to "\n" and "\r\n". The reason is that nobody uses Unicode newlines or "\r" in practice. A positive side effect of the change is that newline-handling code became simpler (and likely faster).
8 years ago
var details = peg$posDetailsCache[pos], p;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Optimize location info computation Before this commit, position details (line and column) weren't computed efficiently from the current parse position. There was a cache but it held only one item and it was rarely hit in practice. This resulted in frequent rescanning of the whole input when the |location| function was used in various places in a grammar. This commit extends the cache to remember position details for any position they were ever computed for. In case of a cache miss, the cache is searched for a value corresponding to the nearest lower position, which is then used to compute position info for the desired position (which is then cached). The whole input never needs to be rescanned. No items are ever evicted from the cache. I think this is fine as the max number of entries is the length of the input. If this becomes a problem I can introduce some eviction logic later. The performance impact of this change is significant. As the benchmark suite doesn't contain any grammar with |location| calls I just used a little ad-hoc benchmark script which measured time to parse the grammar of PEG.js itself (which contains |location| calls): var fs = require("fs"), parser = require("./lib/parser"); var grammar = fs.readFileSync("./src/parser.pegjs", "utf-8"), startTime, endTime; startTime = (new Date()).getTime(); parser.parse(grammar); endTime = (new Date()).getTime(); console.log(endTime - startTime); The measured time went from ~293 ms to ~54 ms on my machine. Fixes #337.
9 years ago
if (details) {
return details;
} else {
p = pos - 1;
while (!peg$posDetailsCache[p]) {
p--;
}
details = peg$posDetailsCache[p];
details = {
line: details.line,
Remove support for newlines other than "\n" and "\r\n" Before this commit, generated parsers considered the following character sequences as newlines: Sequence Description ------------------------------ "\n" Unix "\r" Old Mac "\r\n" Windows "\u2028" line separator "\u2029" paragraph separator This commit limits the sequences only to "\n" and "\r\n". The reason is that nobody uses Unicode newlines or "\r" in practice. A positive side effect of the change is that newline-handling code became simpler (and likely faster).
8 years ago
column: details.column
Optimize location info computation Before this commit, position details (line and column) weren't computed efficiently from the current parse position. There was a cache but it held only one item and it was rarely hit in practice. This resulted in frequent rescanning of the whole input when the |location| function was used in various places in a grammar. This commit extends the cache to remember position details for any position they were ever computed for. In case of a cache miss, the cache is searched for a value corresponding to the nearest lower position, which is then used to compute position info for the desired position (which is then cached). The whole input never needs to be rescanned. No items are ever evicted from the cache. I think this is fine as the max number of entries is the length of the input. If this becomes a problem I can introduce some eviction logic later. The performance impact of this change is significant. As the benchmark suite doesn't contain any grammar with |location| calls I just used a little ad-hoc benchmark script which measured time to parse the grammar of PEG.js itself (which contains |location| calls): var fs = require("fs"), parser = require("./lib/parser"); var grammar = fs.readFileSync("./src/parser.pegjs", "utf-8"), startTime, endTime; startTime = (new Date()).getTime(); parser.parse(grammar); endTime = (new Date()).getTime(); console.log(endTime - startTime); The measured time went from ~293 ms to ~54 ms on my machine. Fixes #337.
9 years ago
};
while (p < pos) {
Detect newlines using charCodeAt instead of charCode In generated parsers, detect newlines using charCodeAt instead of charCode. This should be slightly faster.
8 years ago
if (input.charCodeAt(p) === 10) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
details.line++;
details.column = 1;
} else {
details.column++;
}
Fix complaints from `make hint`
9 years ago
p++;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Optimize location info computation Before this commit, position details (line and column) weren't computed efficiently from the current parse position. There was a cache but it held only one item and it was rarely hit in practice. This resulted in frequent rescanning of the whole input when the |location| function was used in various places in a grammar. This commit extends the cache to remember position details for any position they were ever computed for. In case of a cache miss, the cache is searched for a value corresponding to the nearest lower position, which is then used to compute position info for the desired position (which is then cached). The whole input never needs to be rescanned. No items are ever evicted from the cache. I think this is fine as the max number of entries is the length of the input. If this becomes a problem I can introduce some eviction logic later. The performance impact of this change is significant. As the benchmark suite doesn't contain any grammar with |location| calls I just used a little ad-hoc benchmark script which measured time to parse the grammar of PEG.js itself (which contains |location| calls): var fs = require("fs"), parser = require("./lib/parser"); var grammar = fs.readFileSync("./src/parser.pegjs", "utf-8"), startTime, endTime; startTime = (new Date()).getTime(); parser.parse(grammar); endTime = (new Date()).getTime(); console.log(endTime - startTime); The measured time went from ~293 ms to ~54 ms on my machine. Fixes #337.
9 years ago
peg$posDetailsCache[pos] = details;
Fix complaints from `make hint`
9 years ago
return details;
Optimize location info computation Before this commit, position details (line and column) weren't computed efficiently from the current parse position. There was a cache but it held only one item and it was rarely hit in practice. This resulted in frequent rescanning of the whole input when the |location| function was used in various places in a grammar. This commit extends the cache to remember position details for any position they were ever computed for. In case of a cache miss, the cache is searched for a value corresponding to the nearest lower position, which is then used to compute position info for the desired position (which is then cached). The whole input never needs to be rescanned. No items are ever evicted from the cache. I think this is fine as the max number of entries is the length of the input. If this becomes a problem I can introduce some eviction logic later. The performance impact of this change is significant. As the benchmark suite doesn't contain any grammar with |location| calls I just used a little ad-hoc benchmark script which measured time to parse the grammar of PEG.js itself (which contains |location| calls): var fs = require("fs"), parser = require("./lib/parser"); var grammar = fs.readFileSync("./src/parser.pegjs", "utf-8"), startTime, endTime; startTime = (new Date()).getTime(); parser.parse(grammar); endTime = (new Date()).getTime(); console.log(endTime - startTime); The measured time went from ~293 ms to ~54 ms on my machine. Fixes #337.
9 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Improve location info in syntax errors Replace |line|, |column|, and |offset| properties of |SyntaxError| with the |location| property. It contains an object similar to the one returned by the |location| function available in action code: { start: { offset: 23, line: 5, column: 6 }, end: { offset: 25, line: 5, column: 8 } } For syntax errors produced in the middle of the input, |start| refers to the first unparsed character and |end| refers to the character behind it (meaning the span is 1 character). This corresponds to the portion of the input in the |found| property. For syntax errors produced the end of the input, both |start| and |end| refer to a character past the end of the input (meaning the span is 0 characters). For syntax errors produced by calling |expected| or |error| functions in action code the location info is the same as the |location| function would return.
9 years ago
function peg$computeLocation(startPos, endPos) {
var startPosDetails = peg$computePosDetails(startPos),
endPosDetails = peg$computePosDetails(endPos);
return {
start: {
offset: startPos,
line: startPosDetails.line,
column: startPosDetails.column
},
end: {
offset: endPos,
line: endPosDetails.line,
column: endPosDetails.column
}
};
}
Refine error handling further Before this commit, the |expected| and |error| functions didn't halt the parsing immediately, but triggered a regular match failure. After they were called, the parser could backtrack, try another branches, and only if no other branch succeeded, it triggered an exception with information possibly based on parameters passed to the |expected| or |error| function (this depended on positions where failures in other branches have occurred). While nice in theory, this solution didn't work well in practice. There were at least two problems: 1. Action expression could have easily triggered a match failure later in the input than the action itself. This resulted in the action-triggered failure to be shadowed by the expression-triggered one. Consider the following example: integer = digits:[0-9]+ { var result = parseInt(digits.join(""), 10); if (result % 2 === 0) { error("The number must be an odd integer."); return; } return result; } Given input "2", the |[0-9]+| expression would record a match failure at position 1 (an unsuccessful attempt to parse yet another digit after "2"). However, a failure triggered by the |error| call would occur at position 0. This problem could have been solved by silencing match failures in action expressions, but that would lead to severe performance problems (yes, I tried and measured). Other possible solutions are hacks which I didn't want to introduce into PEG.js. 2. Triggering a match failure in action code could have lead to unexpected backtracking. Consider the following example: class = "[" (charRange / char)* "]" charRange = begin:char "-" end:char { if (begin.data.charCodeAt(0) > end.data.charCodeAt(0)) { error("Invalid character range: " + begin + "-" + end + "."); } // ... } char = [a-zA-Z0-9_\-] Given input "[b-a]", the |charRange| rule would fail, but the parser would try the |char| rule and succeed repeatedly, resulting in "b-a" being parsed as a sequence of three |char|'s, which it is not. This problem could have been solved by using negative predicates, but that would complicate the grammar and still wouldn't get rid of unintuitive behavior. Given these problems I decided to change the semantics of the |expected| and |error| functions. They don't interact with regular match failure mechanism anymore, but they cause and immediate parse failure by throwing an exception. I think this is more intuitive behavior with less harmful side effects. The disadvantage of the new approach is that one can't backtrack from an action-triggered error. I don't see this as a big deal as I think this will be rarely needed and one can always use a semantic predicate as a workaround. Speed impact ------------ Before: 993.84 kB/s After: 998.05 kB/s Difference: 0.42% Size impact ----------- Before: 1019968 b After: 975434 b Difference: -4.37% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
function peg$fail(expected) {
if (peg$currPos < peg$maxFailPos) { return; }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Refine error handling further Before this commit, the |expected| and |error| functions didn't halt the parsing immediately, but triggered a regular match failure. After they were called, the parser could backtrack, try another branches, and only if no other branch succeeded, it triggered an exception with information possibly based on parameters passed to the |expected| or |error| function (this depended on positions where failures in other branches have occurred). While nice in theory, this solution didn't work well in practice. There were at least two problems: 1. Action expression could have easily triggered a match failure later in the input than the action itself. This resulted in the action-triggered failure to be shadowed by the expression-triggered one. Consider the following example: integer = digits:[0-9]+ { var result = parseInt(digits.join(""), 10); if (result % 2 === 0) { error("The number must be an odd integer."); return; } return result; } Given input "2", the |[0-9]+| expression would record a match failure at position 1 (an unsuccessful attempt to parse yet another digit after "2"). However, a failure triggered by the |error| call would occur at position 0. This problem could have been solved by silencing match failures in action expressions, but that would lead to severe performance problems (yes, I tried and measured). Other possible solutions are hacks which I didn't want to introduce into PEG.js. 2. Triggering a match failure in action code could have lead to unexpected backtracking. Consider the following example: class = "[" (charRange / char)* "]" charRange = begin:char "-" end:char { if (begin.data.charCodeAt(0) > end.data.charCodeAt(0)) { error("Invalid character range: " + begin + "-" + end + "."); } // ... } char = [a-zA-Z0-9_\-] Given input "[b-a]", the |charRange| rule would fail, but the parser would try the |char| rule and succeed repeatedly, resulting in "b-a" being parsed as a sequence of three |char|'s, which it is not. This problem could have been solved by using negative predicates, but that would complicate the grammar and still wouldn't get rid of unintuitive behavior. Given these problems I decided to change the semantics of the |expected| and |error| functions. They don't interact with regular match failure mechanism anymore, but they cause and immediate parse failure by throwing an exception. I think this is more intuitive behavior with less harmful side effects. The disadvantage of the new approach is that one can't backtrack from an action-triggered error. I don't see this as a big deal as I think this will be rarely needed and one can always use a semantic predicate as a workaround. Speed impact ------------ Before: 993.84 kB/s After: 998.05 kB/s Difference: 0.42% Size impact ----------- Before: 1019968 b After: 975434 b Difference: -4.37% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (peg$currPos > peg$maxFailPos) {
peg$maxFailPos = peg$currPos;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$maxFailExpected = [];
}
peg$maxFailExpected.push(expected);
}
Remove info about found string from syntax errors The |found| property wasn't very useful as it mostly contained just one character or |null| (the exception being syntax errors triggered by |error| or |expected|). Similarly, the "but XXX found" part of the error message (based on the |found| property) wasn't much useful and was redundant in presence of location info. For these reasons, this commit removes the |found| property and corresponding part of the error message from syntax errors. It also modifies error location info slightly to cover a range of 0 characters, not 1 character (except when the error is triggered by |error| or |expected|). This corresponds more precisely to the actual situation. Fixes #372.
9 years ago
function peg$buildException(message, expected, location) {
Error handling: Extract exception building into its own function The exception-creating code will get somewhat hairy soon, so let's make sure them mess will be contained. Implements part of #198.
11 years ago
function cleanupExpected(expected) {
Speed up deduplication of expectations The expectation deduplication algorithm called |Array.prototype.splice| to eliminate each individual duplication, which was slow. This caused problems with grammar/input combinations that generated a lot of expecations (see #377 for an example). This commit replaces the algorithm with much faster one, eliminating the problem.
9 years ago
var i, j;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Error handling: Extract exception building into its own function The exception-creating code will get somewhat hairy soon, so let's make sure them mess will be contained. Implements part of #198.
11 years ago
expected.sort(function(a, b) {
if (a.description < b.description) {
return -1;
} else if (a.description > b.description) {
return 1;
} else {
return 0;
}
});
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
Speed up deduplication of expectations The expectation deduplication algorithm called |Array.prototype.splice| to eliminate each individual duplication, which was slow. This caused problems with grammar/input combinations that generated a lot of expecations (see #377 for an example). This commit replaces the algorithm with much faster one, eliminating the problem.
9 years ago
if (expected.length > 0) {
for (i = 1, j = 1; i < expected.length; i++) {
if (expected[i - 1] !== expected[i]) {
expected[j] = expected[i];
j++;
}
Error handling: Extract exception building into its own function The exception-creating code will get somewhat hairy soon, so let's make sure them mess will be contained. Implements part of #198.
11 years ago
}
Speed up deduplication of expectations The expectation deduplication algorithm called |Array.prototype.splice| to eliminate each individual duplication, which was slow. This caused problems with grammar/input combinations that generated a lot of expecations (see #377 for an example). This commit replaces the algorithm with much faster one, eliminating the problem.
9 years ago
expected.length = j;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
}
Error handling: Extract exception building into its own function The exception-creating code will get somewhat hairy soon, so let's make sure them mess will be contained. Implements part of #198.
11 years ago
Remove info about found string from syntax errors The |found| property wasn't very useful as it mostly contained just one character or |null| (the exception being syntax errors triggered by |error| or |expected|). Similarly, the "but XXX found" part of the error message (based on the |found| property) wasn't much useful and was redundant in presence of location info. For these reasons, this commit removes the |found| property and corresponding part of the error message from syntax errors. It also modifies error location info slightly to cover a range of 0 characters, not 1 character (except when the error is triggered by |error| or |expected|). This corresponds more precisely to the actual situation. Fixes #372.
9 years ago
function buildMessage(expected) {
Fix error messages in certain cases with trailing input In case the generated parser parsed successfully part of input and left some input unparsed (trailing input), the error message produced was sometimes wrong. The code worked correctly only if there were no match failures in the successfully parsed part (highly unlikely). This commit fixes things by explicitly triggering a match failure with the following expectation at the end of the successfully parsed part of the input: peg$fail({ type: "end", description: "end of input" }); This change also made it possible to simplify the |buildMessage| function, which can now ignore the case of no expectations. Fixes #119.
11 years ago
var expectedDescs = new Array(expected.length),
Remove info about found string from syntax errors The |found| property wasn't very useful as it mostly contained just one character or |null| (the exception being syntax errors triggered by |error| or |expected|). Similarly, the "but XXX found" part of the error message (based on the |found| property) wasn't much useful and was redundant in presence of location info. For these reasons, this commit removes the |found| property and corresponding part of the error message from syntax errors. It also modifies error location info slightly to cover a range of 0 characters, not 1 character (except when the error is triggered by |error| or |expected|). This corresponds more precisely to the actual situation. Fixes #372.
9 years ago
expectedDesc, i;
Error handling: Build error message out of |SyntaxError|'s constructor It will be possible to create errors with user-supplied messages soon. The |SyntaxError| class needs to be ready for that. Implements part of #198.
11 years ago
Fix error messages in certain cases with trailing input In case the generated parser parsed successfully part of input and left some input unparsed (trailing input), the error message produced was sometimes wrong. The code worked correctly only if there were no match failures in the successfully parsed part (highly unlikely). This commit fixes things by explicitly triggering a match failure with the following expectation at the end of the successfully parsed part of the input: peg$fail({ type: "end", description: "end of input" }); This change also made it possible to simplify the |buildMessage| function, which can now ignore the case of no expectations. Fixes #119.
11 years ago
for (i = 0; i < expected.length; i++) {
expectedDescs[i] = expected[i].description;
}
Error handling: Build error message out of |SyntaxError|'s constructor It will be possible to create errors with user-supplied messages soon. The |SyntaxError| class needs to be ready for that. Implements part of #198.
11 years ago
Fix error messages in certain cases with trailing input In case the generated parser parsed successfully part of input and left some input unparsed (trailing input), the error message produced was sometimes wrong. The code worked correctly only if there were no match failures in the successfully parsed part (highly unlikely). This commit fixes things by explicitly triggering a match failure with the following expectation at the end of the successfully parsed part of the input: peg$fail({ type: "end", description: "end of input" }); This change also made it possible to simplify the |buildMessage| function, which can now ignore the case of no expectations. Fixes #119.
11 years ago
expectedDesc = expected.length > 1
? expectedDescs.slice(0, -1).join(", ")
Error handling: Build error message out of |SyntaxError|'s constructor It will be possible to create errors with user-supplied messages soon. The |SyntaxError| class needs to be ready for that. Implements part of #198.
11 years ago
+ " or "
Fix error messages in certain cases with trailing input In case the generated parser parsed successfully part of input and left some input unparsed (trailing input), the error message produced was sometimes wrong. The code worked correctly only if there were no match failures in the successfully parsed part (highly unlikely). This commit fixes things by explicitly triggering a match failure with the following expectation at the end of the successfully parsed part of the input: peg$fail({ type: "end", description: "end of input" }); This change also made it possible to simplify the |buildMessage| function, which can now ignore the case of no expectations. Fixes #119.
11 years ago
+ expectedDescs[expected.length - 1]
: expectedDescs[0];
Error handling: Build error message out of |SyntaxError|'s constructor It will be possible to create errors with user-supplied messages soon. The |SyntaxError| class needs to be ready for that. Implements part of #198.
11 years ago
Remove info about found string from syntax errors The |found| property wasn't very useful as it mostly contained just one character or |null| (the exception being syntax errors triggered by |error| or |expected|). Similarly, the "but XXX found" part of the error message (based on the |found| property) wasn't much useful and was redundant in presence of location info. For these reasons, this commit removes the |found| property and corresponding part of the error message from syntax errors. It also modifies error location info slightly to cover a range of 0 characters, not 1 character (except when the error is triggered by |error| or |expected|). This corresponds more precisely to the actual situation. Fixes #372.
9 years ago
return "Expected " + expectedDesc + ".";
Error handling: Build error message out of |SyntaxError|'s constructor It will be possible to create errors with user-supplied messages soon. The |SyntaxError| class needs to be ready for that. Implements part of #198.
11 years ago
}
Error handling: Implement the |error| function The |error| function allows users to report custom match failures inside actions. If the |error| function is called, and the reported match failure turns out to be the cause of a parse error, the error message reported by the parser will be exactly the one specified in the |error| call. Implements part of #198. Speed impact ------------ Before: 999.83 kB/s After: 1000.84 kB/s Difference: 0.10% Size impact ----------- Before: 1017212 b After: 1019968 b Difference: 0.27% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (expected !== null) {
cleanupExpected(expected);
}
Error handling: Extract exception building into its own function The exception-creating code will get somewhat hairy soon, so let's make sure them mess will be contained. Implements part of #198.
11 years ago
Mark |parse| and |SyntaxError| as internal identifiers The |parse| function and the |SyntaxError| exception were meant as internal, so let's mark them as such.
10 years ago
return new peg$SyntaxError(
Remove info about found string from syntax errors The |found| property wasn't very useful as it mostly contained just one character or |null| (the exception being syntax errors triggered by |error| or |expected|). Similarly, the "but XXX found" part of the error message (based on the |found| property) wasn't much useful and was redundant in presence of location info. For these reasons, this commit removes the |found| property and corresponding part of the error message from syntax errors. It also modifies error location info slightly to cover a range of 0 characters, not 1 character (except when the error is triggered by |error| or |expected|). This corresponds more precisely to the actual situation. Fixes #372.
9 years ago
message !== null ? message : buildMessage(expected),
Error handling: Implement the |error| function The |error| function allows users to report custom match failures inside actions. If the |error| function is called, and the reported match failure turns out to be the cause of a parse error, the error message reported by the parser will be exactly the one specified in the |error| call. Implements part of #198. Speed impact ------------ Before: 999.83 kB/s After: 1000.84 kB/s Difference: 0.10% Size impact ----------- Before: 1017212 b After: 1019968 b Difference: 0.27% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
expected,
Improve location info in syntax errors Replace |line|, |column|, and |offset| properties of |SyntaxError| with the |location| property. It contains an object similar to the one returned by the |location| function available in action code: { start: { offset: 23, line: 5, column: 6 }, end: { offset: 25, line: 5, column: 8 } } For syntax errors produced in the middle of the input, |start| refers to the first unparsed character and |end| refers to the character behind it (meaning the span is 1 character). This corresponds to the portion of the input in the |found| property. For syntax errors produced the end of the input, both |start| and |end| refer to a character past the end of the input (meaning the span is 0 characters). For syntax errors produced by calling |expected| or |error| functions in action code the location info is the same as the |location| function would return.
9 years ago
location
Error handling: Extract exception building into its own function The exception-creating code will get somewhat hairy soon, so let's make sure them mess will be contained. Implements part of #198.
11 years ago
);
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
function peg$parseGrammar() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3, s4, s5, s6;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
s1 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s2 = peg$currPos;
s3 = peg$parseInitializer();
if (s3 !== peg$FAILED) {
s4 = peg$parse__();
if (s4 !== peg$FAILED) {
s3 = [s3, s4];
s2 = s3;
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = null;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s3 = [];
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s4 = peg$currPos;
s5 = peg$parseRule();
if (s5 !== peg$FAILED) {
s6 = peg$parse__();
if (s6 !== peg$FAILED) {
s5 = [s5, s6];
s4 = s5;
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s4 !== peg$FAILED) {
while (s4 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s3.push(s4);
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s4 = peg$currPos;
s5 = peg$parseRule();
if (s5 !== peg$FAILED) {
s6 = peg$parse__();
if (s6 !== peg$FAILED) {
s5 = [s5, s6];
s4 = s5;
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c0(s2, s3);
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
function peg$parseInitializer() {
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
var s0, s1, s2;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
s1 = peg$parseCodeBlock();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
s2 = peg$parseEOS();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c1(s1);
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
function peg$parseRule() {
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
var s0, s1, s2, s3, s4, s5, s6, s7;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s1 = peg$parseIdentifierName();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s2 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s3 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s4 = peg$parseStringLiteral();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s4 !== peg$FAILED) {
s5 = peg$parse__();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = null;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s3 !== peg$FAILED) {
PEG.js grammar: Inline trivial character rules
10 years ago
if (input.charCodeAt(peg$currPos) === 61) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$c2;
PEG.js grammar: Inline trivial character rules
10 years ago
peg$currPos++;
} else {
s4 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c3); }
PEG.js grammar: Inline trivial character rules
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s4 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s5 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s5 !== peg$FAILED) {
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s6 = peg$parseChoiceExpression();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s6 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
s7 = peg$parseEOS();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s7 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c4(s1, s3, s6);
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
function peg$parseChoiceExpression() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3, s4, s5, s6, s7;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
s1 = peg$parseActionExpression();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s2 = [];
s3 = peg$currPos;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s4 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s4 !== peg$FAILED) {
PEG.js grammar: Inline trivial character rules
10 years ago
if (input.charCodeAt(peg$currPos) === 47) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$c5;
PEG.js grammar: Inline trivial character rules
10 years ago
peg$currPos++;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c6); }
PEG.js grammar: Inline trivial character rules
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s5 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s6 = peg$parse__();
if (s6 !== peg$FAILED) {
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
s7 = peg$parseActionExpression();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s7 !== peg$FAILED) {
s4 = [s4, s5, s6, s7];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
while (s3 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s2.push(s3);
s3 = peg$currPos;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s4 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s4 !== peg$FAILED) {
PEG.js grammar: Inline trivial character rules
10 years ago
if (input.charCodeAt(peg$currPos) === 47) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$c5;
PEG.js grammar: Inline trivial character rules
10 years ago
peg$currPos++;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c6); }
PEG.js grammar: Inline trivial character rules
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s5 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s6 = peg$parse__();
if (s6 !== peg$FAILED) {
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
s7 = peg$parseActionExpression();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s7 !== peg$FAILED) {
s4 = [s4, s5, s6, s7];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c7(s1, s2);
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
function peg$parseActionExpression() {
var s0, s1, s2, s3, s4;
s0 = peg$currPos;
s1 = peg$parseSequenceExpression();
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
s3 = peg$parse__();
if (s3 !== peg$FAILED) {
s4 = peg$parseCodeBlock();
if (s4 !== peg$FAILED) {
s3 = [s3, s4];
s2 = s3;
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
}
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
}
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = null;
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
}
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c8(s1, s2);
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
}
return s0;
}
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
function peg$parseSequenceExpression() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3, s4, s5;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s1 = peg$parseLabeledExpression();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s2 = [];
s3 = peg$currPos;
s4 = peg$parse__();
if (s4 !== peg$FAILED) {
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s5 = peg$parseLabeledExpression();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$currPos;
s4 = peg$parse__();
if (s4 !== peg$FAILED) {
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s5 = peg$parseLabeledExpression();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c9(s1, s2);
PEG.js grammar: Extract the |ActionExpression| rule Having it separated from the |SequenceExpression| rule is cleaner and more logical.
10 years ago
s0 = s1;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
function peg$parseLabeledExpression() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3, s4, s5;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
s1 = peg$parseIdentifier();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s2 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
PEG.js grammar: Inline trivial character rules
10 years ago
if (input.charCodeAt(peg$currPos) === 58) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$c10;
PEG.js grammar: Inline trivial character rules
10 years ago
peg$currPos++;
} else {
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c11); }
PEG.js grammar: Inline trivial character rules
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s3 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s4 = peg$parse__();
if (s4 !== peg$FAILED) {
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s5 = peg$parsePrefixedExpression();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s5 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c12(s1, s5);
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s0 = peg$parsePrefixedExpression();
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
function peg$parsePrefixedExpression() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: Make rules with operators more generic
10 years ago
s1 = peg$parsePrefixedOperator();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s2 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s3 = peg$parseSuffixedExpression();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c13(s1, s3);
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: Make rules with operators more generic
10 years ago
s0 = peg$parseSuffixedExpression();
}
return s0;
}
function peg$parsePrefixedOperator() {
var s0;
if (input.charCodeAt(peg$currPos) === 36) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c14;
PEG.js grammar: Make rules with operators more generic
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c15); }
PEG.js grammar: Make rules with operators more generic
10 years ago
}
if (s0 === peg$FAILED) {
PEG.js grammar: Inline trivial character rules
10 years ago
if (input.charCodeAt(peg$currPos) === 38) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c16;
PEG.js grammar: Inline trivial character rules
10 years ago
peg$currPos++;
} else {
PEG.js grammar: Make rules with operators more generic
10 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c17); }
PEG.js grammar: Inline trivial character rules
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
if (input.charCodeAt(peg$currPos) === 33) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c18;
PEG.js grammar: Inline trivial character rules
10 years ago
peg$currPos++;
} else {
PEG.js grammar: Make rules with operators more generic
10 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c19); }
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return s0;
}
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
function peg$parseSuffixedExpression() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
s1 = peg$parsePrimaryExpression();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s2 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
PEG.js grammar: Make rules with operators more generic
10 years ago
s3 = peg$parseSuffixedOperator();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c20(s1, s3);
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: Make rules with operators more generic
10 years ago
s0 = peg$parsePrimaryExpression();
}
return s0;
}
function peg$parseSuffixedOperator() {
var s0;
if (input.charCodeAt(peg$currPos) === 63) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c21;
PEG.js grammar: Make rules with operators more generic
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c22); }
PEG.js grammar: Make rules with operators more generic
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 42) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c23;
PEG.js grammar: Make rules with operators more generic
10 years ago
peg$currPos++;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
PEG.js grammar: Make rules with operators more generic
10 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c24); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: Make rules with operators more generic
10 years ago
if (input.charCodeAt(peg$currPos) === 43) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c25;
PEG.js grammar: Make rules with operators more generic
10 years ago
peg$currPos++;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
PEG.js grammar: Make rules with operators more generic
10 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c26); }
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
}
return s0;
}
PEG.js grammar: Append |Expression| to expression rule names Makes the rule names a bit longer but also clearer.
10 years ago
function peg$parsePrimaryExpression() {
PEG.js grammar: Extract the |RuleReferenceExpression| rule This makes the |Primary| rule a bit more tidy.
10 years ago
var s0, s1, s2, s3, s4, s5;
s0 = peg$parseLiteralMatcher();
if (s0 === peg$FAILED) {
s0 = peg$parseCharacterClassMatcher();
if (s0 === peg$FAILED) {
s0 = peg$parseAnyMatcher();
if (s0 === peg$FAILED) {
s0 = peg$parseRuleReferenceExpression();
if (s0 === peg$FAILED) {
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
s0 = peg$parseSemanticPredicateExpression();
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 40) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c27;
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c28); }
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$parse__();
if (s2 !== peg$FAILED) {
s3 = peg$parseChoiceExpression();
if (s3 !== peg$FAILED) {
s4 = peg$parse__();
if (s4 !== peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 41) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$c29;
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
peg$currPos++;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c30); }
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
}
if (s5 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c31(s3);
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
}
PEG.js grammar: Extract the |RuleReferenceExpression| rule This makes the |Primary| rule a bit more tidy.
10 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |RuleReferenceExpression| rule This makes the |Primary| rule a bit more tidy.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |RuleReferenceExpression| rule This makes the |Primary| rule a bit more tidy.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |RuleReferenceExpression| rule This makes the |Primary| rule a bit more tidy.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |RuleReferenceExpression| rule This makes the |Primary| rule a bit more tidy.
10 years ago
}
}
}
}
}
}
return s0;
}
function peg$parseRuleReferenceExpression() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3, s4, s5, s6, s7;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s1 = peg$parseIdentifierName();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$currPos;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s4 = peg$parse__();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s4 !== peg$FAILED) {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s5 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s6 = peg$parseStringLiteral();
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s6 !== peg$FAILED) {
s7 = peg$parse__();
if (s7 !== peg$FAILED) {
s6 = [s6, s7];
s5 = s6;
} else {
peg$currPos = s5;
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
} else {
peg$currPos = s5;
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = null;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s5 !== peg$FAILED) {
PEG.js grammar: Inline trivial character rules
10 years ago
if (input.charCodeAt(peg$currPos) === 61) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s6 = peg$c2;
PEG.js grammar: Inline trivial character rules
10 years ago
peg$currPos++;
} else {
s6 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c3); }
PEG.js grammar: Inline trivial character rules
10 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s6 !== peg$FAILED) {
s4 = [s4, s5, s6];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
peg$silentFails--;
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c32(s1);
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
function peg$parseSemanticPredicateExpression() {
var s0, s1, s2, s3;
s0 = peg$currPos;
PEG.js grammar: Make rules with operators more generic
10 years ago
s1 = peg$parseSemanticPredicateOperator();
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
if (s1 !== peg$FAILED) {
s2 = peg$parse__();
if (s2 !== peg$FAILED) {
s3 = peg$parseCodeBlock();
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c33(s1, s3);
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
}
PEG.js grammar: Make rules with operators more generic
10 years ago
return s0;
}
function peg$parseSemanticPredicateOperator() {
var s0;
if (input.charCodeAt(peg$currPos) === 38) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c16;
PEG.js grammar: Make rules with operators more generic
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c17); }
PEG.js grammar: Make rules with operators more generic
10 years ago
}
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 33) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c18;
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
peg$currPos++;
} else {
PEG.js grammar: Make rules with operators more generic
10 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c19); }
PEG.js grammar: Extract the |SemanticPredicateExpression| rule Semantic predicates are kind of |PrimaryExpression|, not kind of |PrefixedExpression|. Therefore I extracted a rule for them and referenced it from the |PrimaryExpression|.
10 years ago
}
}
return s0;
}
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
function peg$parseSourceCharacter() {
var s0;
if (input.length > peg$currPos) {
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c34); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parseWhiteSpace() {
var s0, s1;
peg$silentFails++;
if (input.charCodeAt(peg$currPos) === 9) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c36;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c37); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 11) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c38;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c39); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 12) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c40;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c41); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 32) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c42;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c43); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 160) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c44;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c45); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 65279) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c46;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c47); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
s0 = peg$parseZs();
}
}
}
}
}
}
peg$silentFails--;
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c35); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parseLineTerminator() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c48.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c49); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parseLineTerminatorSequence() {
var s0, s1;
peg$silentFails++;
if (input.charCodeAt(peg$currPos) === 10) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c51;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c52); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c53) {
s0 = peg$c53;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos += 2;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c54); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 13) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c55;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c56); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 8232) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c57;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c58); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 8233) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c59;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c60); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
}
}
}
}
peg$silentFails--;
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c50); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parseComment() {
var s0, s1;
peg$silentFails++;
s0 = peg$parseMultiLineComment();
if (s0 === peg$FAILED) {
s0 = peg$parseSingleLineComment();
}
peg$silentFails--;
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c61); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parseMultiLineComment() {
var s0, s1, s2, s3, s4, s5;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c62) {
s1 = peg$c62;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
peg$currPos += 2;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c63); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = [];
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c64) {
s5 = peg$c64;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
peg$currPos += 2;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c65); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c64) {
s5 = peg$c64;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
peg$currPos += 2;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c65); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
}
if (s2 !== peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c64) {
s3 = peg$c64;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
peg$currPos += 2;
} else {
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c65); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s3 !== peg$FAILED) {
s1 = [s1, s2, s3];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
return s0;
}
function peg$parseMultiLineCommentNoLineTerminator() {
var s0, s1, s2, s3, s4, s5;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c62) {
s1 = peg$c62;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos += 2;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c63); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = [];
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c64) {
s5 = peg$c64;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos += 2;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c65); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s5 === peg$FAILED) {
s5 = peg$parseLineTerminator();
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c64) {
s5 = peg$c64;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos += 2;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c65); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s5 === peg$FAILED) {
s5 = peg$parseLineTerminator();
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
}
if (s2 !== peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c64) {
s3 = peg$c64;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos += 2;
} else {
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c65); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s3 !== peg$FAILED) {
s1 = [s1, s2, s3];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parseSingleLineComment() {
var s0, s1, s2, s3, s4, s5;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c66) {
s1 = peg$c66;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos += 2;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c67); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = [];
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
s5 = peg$parseLineTerminator();
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
s5 = peg$parseLineTerminator();
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
function peg$parseIdentifier() {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
var s0, s1, s2;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
s1 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$silentFails++;
s2 = peg$parseReservedWord();
peg$silentFails--;
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s1;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$parseIdentifierName();
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c68(s2);
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = s1;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
return s0;
}
function peg$parseIdentifierName() {
var s0, s1, s2, s3;
peg$silentFails++;
s0 = peg$currPos;
s1 = peg$parseIdentifierStart();
if (s1 !== peg$FAILED) {
s2 = [];
s3 = peg$parseIdentifierPart();
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$parseIdentifierPart();
}
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c70(s1, s2);
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
peg$silentFails--;
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c69); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseIdentifierStart() {
var s0, s1, s2;
s0 = peg$parseUnicodeLetter();
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 36) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c14;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c15); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 95) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c71;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c72); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c73;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$parseUnicodeEscapeSequence();
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c75(s2);
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
}
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseIdentifierPart() {
var s0;
s0 = peg$parseIdentifierStart();
if (s0 === peg$FAILED) {
s0 = peg$parseUnicodeCombiningMark();
if (s0 === peg$FAILED) {
s0 = peg$parseNd();
if (s0 === peg$FAILED) {
s0 = peg$parsePc();
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 8204) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c76;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c77); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 8205) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c78;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c79); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
}
Text nodes: Use text nodes in PEG.js grammar
12 years ago
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseUnicodeLetter() {
var s0;
s0 = peg$parseLu();
if (s0 === peg$FAILED) {
s0 = peg$parseLl();
if (s0 === peg$FAILED) {
s0 = peg$parseLt();
if (s0 === peg$FAILED) {
s0 = peg$parseLm();
if (s0 === peg$FAILED) {
s0 = peg$parseLo();
if (s0 === peg$FAILED) {
s0 = peg$parseNl();
}
}
}
Text nodes: Use text nodes in PEG.js grammar
12 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
return s0;
}
function peg$parseUnicodeCombiningMark() {
var s0;
s0 = peg$parseMn();
if (s0 === peg$FAILED) {
s0 = peg$parseMc();
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
return s0;
}
function peg$parseReservedWord() {
var s0;
s0 = peg$parseKeyword();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = peg$parseFutureReservedWord();
if (s0 === peg$FAILED) {
s0 = peg$parseNullToken();
if (s0 === peg$FAILED) {
s0 = peg$parseBooleanLiteral();
}
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
function peg$parseKeyword() {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
var s0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = peg$parseBreakToken();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = peg$parseCaseToken();
if (s0 === peg$FAILED) {
s0 = peg$parseCatchToken();
if (s0 === peg$FAILED) {
s0 = peg$parseContinueToken();
if (s0 === peg$FAILED) {
s0 = peg$parseDebuggerToken();
if (s0 === peg$FAILED) {
s0 = peg$parseDefaultToken();
if (s0 === peg$FAILED) {
s0 = peg$parseDeleteToken();
if (s0 === peg$FAILED) {
s0 = peg$parseDoToken();
if (s0 === peg$FAILED) {
s0 = peg$parseElseToken();
if (s0 === peg$FAILED) {
s0 = peg$parseFinallyToken();
if (s0 === peg$FAILED) {
s0 = peg$parseForToken();
if (s0 === peg$FAILED) {
s0 = peg$parseFunctionToken();
if (s0 === peg$FAILED) {
s0 = peg$parseIfToken();
if (s0 === peg$FAILED) {
s0 = peg$parseInstanceofToken();
if (s0 === peg$FAILED) {
s0 = peg$parseInToken();
if (s0 === peg$FAILED) {
s0 = peg$parseNewToken();
if (s0 === peg$FAILED) {
s0 = peg$parseReturnToken();
if (s0 === peg$FAILED) {
s0 = peg$parseSwitchToken();
if (s0 === peg$FAILED) {
s0 = peg$parseThisToken();
if (s0 === peg$FAILED) {
s0 = peg$parseThrowToken();
if (s0 === peg$FAILED) {
s0 = peg$parseTryToken();
if (s0 === peg$FAILED) {
s0 = peg$parseTypeofToken();
if (s0 === peg$FAILED) {
s0 = peg$parseVarToken();
if (s0 === peg$FAILED) {
s0 = peg$parseVoidToken();
if (s0 === peg$FAILED) {
s0 = peg$parseWhileToken();
if (s0 === peg$FAILED) {
s0 = peg$parseWithToken();
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
return s0;
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
function peg$parseFutureReservedWord() {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
var s0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = peg$parseClassToken();
if (s0 === peg$FAILED) {
s0 = peg$parseConstToken();
if (s0 === peg$FAILED) {
s0 = peg$parseEnumToken();
if (s0 === peg$FAILED) {
s0 = peg$parseExportToken();
if (s0 === peg$FAILED) {
s0 = peg$parseExtendsToken();
if (s0 === peg$FAILED) {
s0 = peg$parseImportToken();
if (s0 === peg$FAILED) {
s0 = peg$parseSuperToken();
}
}
}
}
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
return s0;
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
function peg$parseBooleanLiteral() {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
var s0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = peg$parseTrueToken();
if (s0 === peg$FAILED) {
s0 = peg$parseFalseToken();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
return s0;
}
function peg$parseLiteralMatcher() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$silentFails++;
s0 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s1 = peg$parseStringLiteral();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 105) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c81;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c82); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = null;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c83(s1, s2);
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s0 = s1;
Implement case-insensitive literal matching
13 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Implement case-insensitive literal matching
13 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
peg$silentFails--;
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c80); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseStringLiteral() {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
var s0, s1, s2, s3;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$silentFails++;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 34) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c85;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c86); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s2 = [];
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s3 = peg$parseDoubleStringCharacter();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
while (s3 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s2.push(s3);
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s3 = peg$parseDoubleStringCharacter();
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 34) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$c85;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c86); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c87(s2);
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 39) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c88;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c89); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = [];
s3 = peg$parseSingleStringCharacter();
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$parseSingleStringCharacter();
}
if (s2 !== peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 39) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$c88;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c89); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c87(s2);
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$silentFails--;
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c84); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseDoubleStringCharacter() {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
var s0, s1, s2;
s0 = peg$currPos;
s1 = peg$currPos;
peg$silentFails++;
if (input.charCodeAt(peg$currPos) === 34) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c85;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c86); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c73;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s2 = peg$parseLineTerminator();
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
peg$silentFails--;
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = void 0;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s1;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s2 = peg$parseSourceCharacter();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c90();
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Reset parser position when action returns |null| The change does not change the benchmark suite execution speed statistically significantly. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 128.20 kB/s 128.03 kB/s 2 130.36 kB/s 128.73 kB/s 3 126.53 kB/s 129.72 kB/s 4 127.46 kB/s 127.48 kB/s 5 127.63 kB/s 128.53 kB/s ----------------------------------- Average 128.04 kB/s 125.50 kB/s ----------------------------------- Closes GH-25.
13 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c73;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s1 !== peg$FAILED) {
s2 = peg$parseEscapeSequence();
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c75(s2);
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s0 = peg$parseLineContinuation();
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseSingleStringCharacter() {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
var s0, s1, s2;
s0 = peg$currPos;
s1 = peg$currPos;
peg$silentFails++;
if (input.charCodeAt(peg$currPos) === 39) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c88;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c89); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c73;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s2 = peg$parseLineTerminator();
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
peg$silentFails--;
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = void 0;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s1;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s2 = peg$parseSourceCharacter();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c90();
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c73;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$parseEscapeSequence();
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c75(s2);
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s0 === peg$FAILED) {
s0 = peg$parseLineContinuation();
}
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseCharacterClassMatcher() {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
var s0, s1, s2, s3, s4, s5;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$silentFails++;
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 91) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c92;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c93); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s1 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 94) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c94;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
Implemented negative character classes (e.g. [^a-z]).
14 years ago
} else {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c95); }
Implemented negative character classes (e.g. [^a-z]).
14 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = null;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s2 !== peg$FAILED) {
s3 = [];
s4 = peg$parseClassCharacterRange();
if (s4 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s4 = peg$parseClassCharacter();
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
while (s4 !== peg$FAILED) {
s3.push(s4);
s4 = peg$parseClassCharacterRange();
if (s4 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s4 = peg$parseClassCharacter();
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s3 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 93) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$c96;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s4 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c97); }
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s4 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 105) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$c81;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c82); }
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = null;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
if (s5 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c98(s2, s3, s5);
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Implemented negative character classes (e.g. [^a-z]).
14 years ago
} else {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Implemented negative character classes (e.g. [^a-z]).
14 years ago
}
} else {
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
peg$silentFails--;
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c91); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
function peg$parseClassCharacterRange() {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
var s0, s1, s2, s3;
s0 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s1 = peg$parseClassCharacter();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 45) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c99;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c100); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s3 = peg$parseClassCharacter();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c101(s1, s3);
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseClassCharacter() {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
var s0, s1, s2;
s0 = peg$currPos;
s1 = peg$currPos;
peg$silentFails++;
if (input.charCodeAt(peg$currPos) === 93) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c96;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c97); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c73;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s2 = peg$parseLineTerminator();
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
peg$silentFails--;
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = void 0;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s1;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s2 = peg$parseSourceCharacter();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c90();
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c73;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$parseEscapeSequence();
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c75(s2);
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s0 === peg$FAILED) {
s0 = peg$parseLineContinuation();
}
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseLineContinuation() {
var s0, s1, s2;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c73;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s2 = peg$parseLineTerminatorSequence();
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c102();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
return s0;
}
function peg$parseEscapeSequence() {
var s0, s1, s2, s3;
s0 = peg$parseCharacterEscapeSequence();
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 48) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c103;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c104); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseDecimalDigit();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c105();
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Rewrite variable handling in generated parsers Before this commit, variables for saving match results and parse positions in generated parsers were not used efficiently. Each rule basically used its own variable(s) for storing the data, with names generated sequentially during code emitting. There was no reuse of variables and a lot of unnecessary assignments between them. It is easy to see that both match results and parse positions can actually be stored on a stack that grows as the parser walks deeper in the grammar tree and shrinks as it returns. Moreover, if one creates a new stack for each rule the parser enters, its maximum depth can be computed statically from the grammar. This allows us to implement the stack not as an array, but as a set of numbered variables in each function that handles parsing of a grammar rule, avoiding potentially slow array accesses. This commit implements the idea from the previous paragraph, using separate stack for match results and for parse positions. As a result, defined variables are reused and unnecessary copying avoided. Speed implications ------------------ This change speeds up the benchmark suite execution by 2.14%. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 129.01 kB/s 131.98 kB/s 2 129.39 kB/s 130.13 kB/s 3 128.63 kB/s 132.57 kB/s 4 127.53 kB/s 129.82 kB/s 5 127.98 kB/s 131.80 kB/s ----------------------------------- Average 128.51 kB/s 131.26 kB/s ----------------------------------- Size implications ----------------- This change makes a sample of generated parsers 8.60% smaller: Before: $ wc -c src/parser.js examples/*.js 110867 src/parser.js 13886 examples/arithmetics.js 450125 examples/css.js 632390 examples/javascript.js 61365 examples/json.js 1268633 total After: $ wc -c src/parser.js examples/*.js 99597 src/parser.js 13077 examples/arithmetics.js 399893 examples/css.js 592044 examples/javascript.js 54797 examples/json.js 1159408 total
13 years ago
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (s0 === peg$FAILED) {
s0 = peg$parseHexEscapeSequence();
if (s0 === peg$FAILED) {
s0 = peg$parseUnicodeEscapeSequence();
}
}
}
return s0;
}
function peg$parseCharacterEscapeSequence() {
var s0;
s0 = peg$parseSingleEscapeCharacter();
if (s0 === peg$FAILED) {
s0 = peg$parseNonEscapeCharacter();
}
return s0;
}
function peg$parseSingleEscapeCharacter() {
var s0, s1;
if (input.charCodeAt(peg$currPos) === 39) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c88;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c89); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 34) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c85;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c86); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 92) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c73;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c74); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 98) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c106;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c107); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c108();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
s0 = s1;
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 102) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c109;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c110); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c111();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
s0 = s1;
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 110) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c112;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c113); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c114();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
s0 = s1;
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 114) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c115;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c116); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c117();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
s0 = s1;
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 116) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c118;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c119); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c120();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
s0 = s1;
if (s0 === peg$FAILED) {
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 118) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c121;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c122); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s1 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c123();
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
s0 = s1;
}
}
}
}
}
}
}
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseNonEscapeCharacter() {
var s0, s1, s2;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s1 = peg$currPos;
peg$silentFails++;
s2 = peg$parseEscapeCharacter();
if (s2 === peg$FAILED) {
s2 = peg$parseLineTerminator();
}
peg$silentFails--;
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = void 0;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos = s1;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
s2 = peg$parseSourceCharacter();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c90();
Remove an error check after calling action code The error check was useful when actions could have returned |null| to trigger a match failure. This is no longer supported so the check isn't needed anymore. Speed impact ------------ Before: 1022.70 kB/s After: 1035.45 kB/s Difference: 1.24% Size impact ----------- Before: 975434 b After: 931540 b Difference: -4.50% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = s1;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Reset parser position when action returns |null| The change does not change the benchmark suite execution speed statistically significantly. Detailed results (benchmark suite totals as reported by "jake benchmark" on Node.js 0.4.8): ----------------------------------- Test # Before After ----------------------------------- 1 128.20 kB/s 128.03 kB/s 2 130.36 kB/s 128.73 kB/s 3 126.53 kB/s 129.72 kB/s 4 127.46 kB/s 127.48 kB/s 5 127.63 kB/s 128.53 kB/s ----------------------------------- Average 128.04 kB/s 125.50 kB/s ----------------------------------- Closes GH-25.
13 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseEscapeCharacter() {
var s0;
s0 = peg$parseSingleEscapeCharacter();
if (s0 === peg$FAILED) {
s0 = peg$parseDecimalDigit();
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 120) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c124;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c125); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
if (s0 === peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 117) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$c126;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c127); }
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
}
}
}
}
return s0;
}
PEG.js grammar: Capitalize rule names When rule names are capitalized, it's easier to visually distinguish them from non-capitalized label names. Moreover, I use capitalized rule names in all my grammars these days.
10 years ago
function peg$parseHexEscapeSequence() {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
var s0, s1, s2, s3, s4, s5;
s0 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (input.charCodeAt(peg$currPos) === 120) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c124;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c125); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
s3 = peg$currPos;
s4 = peg$parseHexDigit();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s4 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s5 = peg$parseHexDigit();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s5 !== peg$FAILED) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
if (s3 !== peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = input.substring(s2, peg$currPos);
} else {
s2 = s3;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c128(s2);
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = s1;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
function peg$parseUnicodeEscapeSequence() {
var s0, s1, s2, s3, s4, s5, s6, s7;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
if (input.charCodeAt(peg$currPos) === 117) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c126;
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
peg$currPos++;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c127); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s1 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s2 = peg$currPos;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s3 = peg$currPos;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s4 = peg$parseHexDigit();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s4 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s5 = peg$parseHexDigit();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s5 !== peg$FAILED) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s6 = peg$parseHexDigit();
if (s6 !== peg$FAILED) {
s7 = peg$parseHexDigit();
if (s7 !== peg$FAILED) {
s4 = [s4, s5, s6, s7];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
} else {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
Make the generated parsers standalone (no runtime is required). This and also speeds up the benchmark suite execution by 7.83 % on V8. Detailed results (benchmark suite totals): --------------------------------- Test # Before After --------------------------------- 1 26.17 kB/s 28.16 kB/s 2 26.05 kB/s 28.16 kB/s 3 25.99 kB/s 28.10 kB/s 4 26.13 kB/s 28.11 kB/s 5 26.14 kB/s 28.07 kB/s --------------------------------- Average 26.10 kB/s 28.14 kB/s --------------------------------- Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
14 years ago
}
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
if (s3 !== peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = input.substring(s2, peg$currPos);
} else {
s2 = s3;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (s2 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c128(s2);
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s0 = s1;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
} else {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Move lot of stuff in generated parsers into the |parse| method We want to have the rule parsing functions inside the |parse| method because we want them to share a common environment. In the future, initializers will be executed in this enviromnent and thus functions and variables defined by them will be accessible to the rule parsing functions. Moving various private properties from the parser object into the |parse| method was not strictly necessary, but it was a natural step after moving the functions.
14 years ago
}
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for strings/literals/classes
10 years ago
function peg$parseDecimalDigit() {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c129.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c130); }
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parseHexDigit() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c131.test(input.charAt(peg$currPos))) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c132); }
PEG.js grammar: Extract the |AnyMatcher| rule This makes the |Primary| rule a bit more tidy. Also, matching the |.| character really belongs to the lexical part of the grammar, next to literals and character classes.
10 years ago
}
return s0;
}
function peg$parseAnyMatcher() {
var s0, s1;
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 46) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c133;
PEG.js grammar: Extract the |AnyMatcher| rule This makes the |Primary| rule a bit more tidy. Also, matching the |.| character really belongs to the lexical part of the grammar, next to literals and character classes.
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c134); }
PEG.js grammar: Extract the |AnyMatcher| rule This makes the |Primary| rule a bit more tidy. Also, matching the |.| character really belongs to the lexical part of the grammar, next to literals and character classes.
10 years ago
}
if (s1 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c135();
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
PEG.js grammar: Extract the |AnyMatcher| rule This makes the |Primary| rule a bit more tidy. Also, matching the |.| character really belongs to the lexical part of the grammar, next to literals and character classes.
10 years ago
s0 = s1;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
return s0;
}
function peg$parseCodeBlock() {
var s0, s1, s2, s3;
peg$silentFails++;
s0 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 123) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c137;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c138); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$parseCode();
if (s2 !== peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 125) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$c139;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c140); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
if (s3 !== peg$FAILED) {
Rename |reportedPos| to |savedPos| Preform the following renames: * |reportedPos| -> |savedPos| (abstract machine variable) * |peg$reportedPos| -> |peg$savedPos| (variable in generated code) * |REPORT_SAVED_POS| -> |LOAD_SAVED_POS| (instruction) * |REPORT_CURR_POS| -> |UPDATE_SAVED_POS| (instruction) The idea is that the name |reportedPos| is no longer accurate after the |location| change (seea the previous commit) because now both |reportedPos| and |currPos| are reported to user code. Renaming to |savedPos| resolves this inaccuracy. There is probably some better name for the concept than quite generic |savedPos|, but it doesn't come to me.
9 years ago
peg$savedPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s1 = peg$c141(s2);
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
peg$silentFails--;
if (s0 === peg$FAILED) {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c136); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
return s0;
}
function peg$parseCode() {
var s0, s1, s2, s3, s4, s5;
s0 = peg$currPos;
s1 = [];
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s2 = [];
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c142.test(input.charAt(peg$currPos))) {
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s5 = input.charAt(peg$currPos);
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c143); }
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
if (s3 !== peg$FAILED) {
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c142.test(input.charAt(peg$currPos))) {
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s5 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c143); }
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
}
} else {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
if (s2 === peg$FAILED) {
s2 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 123) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$c137;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c138); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
if (s3 !== peg$FAILED) {
s4 = peg$parseCode();
if (s4 !== peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 125) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$c139;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c140); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
if (s5 !== peg$FAILED) {
s3 = [s3, s4, s5];
s2 = s3;
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
}
while (s2 !== peg$FAILED) {
s1.push(s2);
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s2 = [];
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c142.test(input.charAt(peg$currPos))) {
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s5 = input.charAt(peg$currPos);
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c143); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
if (s3 !== peg$FAILED) {
while (s3 !== peg$FAILED) {
s2.push(s3);
s3 = peg$currPos;
s4 = peg$currPos;
peg$silentFails++;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c142.test(input.charAt(peg$currPos))) {
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
s5 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c143); }
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
peg$silentFails--;
if (s5 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = void 0;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
} else {
peg$currPos = s4;
Regenerate lib/parser.js after bytecode changes
10 years ago
s4 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
if (s4 !== peg$FAILED) {
s5 = peg$parseSourceCharacter();
if (s5 !== peg$FAILED) {
s4 = [s4, s5];
s3 = s4;
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
} else {
peg$currPos = s3;
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
}
} else {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve the |Code| rule a bit Instead of matching segments between blocks character by character, match them as a whole. Also align the style with other similar rules (e.g. the comment ones).
10 years ago
}
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
if (s2 === peg$FAILED) {
s2 = peg$currPos;
if (input.charCodeAt(peg$currPos) === 123) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s3 = peg$c137;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
s3 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c138); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
if (s3 !== peg$FAILED) {
s4 = peg$parseCode();
if (s4 !== peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 125) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s5 = peg$c139;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
peg$currPos++;
} else {
s5 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c140); }
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
if (s5 !== peg$FAILED) {
s3 = [s3, s4, s5];
s2 = s3;
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
}
}
if (s1 !== peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = input.substring(s0, peg$currPos);
} else {
s0 = s1;
PEG.js grammar: Improve code block handling * Rename the |Action| rule to |CodeBlock| (it better describes what the rule matches). * Implement the rule in a simpler way and move it after more basic lexical elements.
10 years ago
}
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
return s0;
}
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
function peg$parseLl() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c144.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c145); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseLm() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c146.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c147); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseLo() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c148.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c149); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseLt() {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c150.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c151); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseLu() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c152.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c153); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseMc() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c154.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c155); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseMn() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c156.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c157); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseNd() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c158.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c159); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseNl() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c160.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c161); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parsePc() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c162.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c163); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseZs() {
var s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$c164.test(input.charAt(peg$currPos))) {
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
s0 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s0 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c165); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseBreakToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c166) {
s1 = peg$c166;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c167); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseCaseToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c168) {
s1 = peg$c168;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c169); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseCatchToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c170) {
s1 = peg$c170;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c171); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseClassToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c172) {
s1 = peg$c172;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c173); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseConstToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c174) {
s1 = peg$c174;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c175); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseContinueToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 8) === peg$c176) {
s1 = peg$c176;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 8;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c177); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseDebuggerToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 8) === peg$c178) {
s1 = peg$c178;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 8;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c179); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseDefaultToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 7) === peg$c180) {
s1 = peg$c180;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 7;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c181); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseDeleteToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 6) === peg$c182) {
s1 = peg$c182;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 6;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c183); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseDoToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c184) {
s1 = peg$c184;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 2;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c185); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseElseToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c186) {
s1 = peg$c186;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c187); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseEnumToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c188) {
s1 = peg$c188;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c189); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseExportToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 6) === peg$c190) {
s1 = peg$c190;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 6;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c191); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseExtendsToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 7) === peg$c192) {
s1 = peg$c192;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 7;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c193); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseFalseToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c194) {
s1 = peg$c194;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c195); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseFinallyToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 7) === peg$c196) {
s1 = peg$c196;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 7;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c197); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseForToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 3) === peg$c198) {
s1 = peg$c198;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 3;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c199); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseFunctionToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 8) === peg$c200) {
s1 = peg$c200;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 8;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c201); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseIfToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c202) {
s1 = peg$c202;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 2;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c203); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseImportToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 6) === peg$c204) {
s1 = peg$c204;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 6;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c205); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseInstanceofToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 10) === peg$c206) {
s1 = peg$c206;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 10;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c207); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseInToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 2) === peg$c208) {
s1 = peg$c208;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 2;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c209); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseNewToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 3) === peg$c210) {
s1 = peg$c210;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 3;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c211); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseNullToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c212) {
s1 = peg$c212;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c213); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseReturnToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 6) === peg$c214) {
s1 = peg$c214;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 6;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c215); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseSuperToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c216) {
s1 = peg$c216;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c217); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseSwitchToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 6) === peg$c218) {
s1 = peg$c218;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 6;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c219); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseThisToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c220) {
s1 = peg$c220;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c221); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseThrowToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c222) {
s1 = peg$c222;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c223); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseTrueToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c224) {
s1 = peg$c224;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c225); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseTryToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 3) === peg$c226) {
s1 = peg$c226;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 3;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c227); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseTypeofToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 6) === peg$c228) {
s1 = peg$c228;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 6;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c229); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseVarToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 3) === peg$c230) {
s1 = peg$c230;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 3;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c231); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseVoidToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c232) {
s1 = peg$c232;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c233); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseWhileToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 5) === peg$c234) {
s1 = peg$c234;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 5;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c235); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
return s0;
}
function peg$parseWithToken() {
var s0, s1, s2, s3;
s0 = peg$currPos;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (input.substr(peg$currPos, 4) === peg$c236) {
s1 = peg$c236;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
peg$currPos += 4;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c237); }
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s1 !== peg$FAILED) {
s2 = peg$currPos;
peg$silentFails++;
s3 = peg$parseIdentifierPart();
peg$silentFails--;
if (s3 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = void 0;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
} else {
peg$currPos = s2;
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for identifiers This change has two side effects: * Label names can no longer be JavaScript reserved words. * |$| is allowed again in label names. However, because of the preference rules, names starting with it will be usually parsed as a text operator followed by another identifier (denoting a rule reference or label name).
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like rules for skipped elements
10 years ago
}
return s0;
}
function peg$parse__() {
var s0, s1;
s0 = [];
s1 = peg$parseWhiteSpace();
if (s1 === peg$FAILED) {
s1 = peg$parseLineTerminatorSequence();
if (s1 === peg$FAILED) {
s1 = peg$parseComment();
}
}
while (s1 !== peg$FAILED) {
s0.push(s1);
s1 = peg$parseWhiteSpace();
if (s1 === peg$FAILED) {
s1 = peg$parseLineTerminatorSequence();
if (s1 === peg$FAILED) {
s1 = peg$parseComment();
}
}
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
return s0;
}
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
function peg$parse_() {
var s0, s1;
s0 = [];
s1 = peg$parseWhiteSpace();
if (s1 === peg$FAILED) {
s1 = peg$parseMultiLineCommentNoLineTerminator();
}
while (s1 !== peg$FAILED) {
s0.push(s1);
s1 = peg$parseWhiteSpace();
if (s1 === peg$FAILED) {
s1 = peg$parseMultiLineCommentNoLineTerminator();
}
}
return s0;
}
function peg$parseEOS() {
var s0, s1, s2, s3;
s0 = peg$currPos;
s1 = peg$parse__();
if (s1 !== peg$FAILED) {
if (input.charCodeAt(peg$currPos) === 59) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = peg$c238;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
peg$currPos++;
} else {
s2 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c239); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s0 === peg$FAILED) {
s0 = peg$currPos;
s1 = peg$parse_();
if (s1 !== peg$FAILED) {
s2 = peg$parseSingleLineComment();
if (s2 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s2 = null;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s2 !== peg$FAILED) {
s3 = peg$parseLineTerminatorSequence();
if (s3 !== peg$FAILED) {
s1 = [s1, s2, s3];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
if (s0 === peg$FAILED) {
s0 = peg$currPos;
s1 = peg$parse__();
if (s1 !== peg$FAILED) {
s2 = peg$parseEOF();
if (s2 !== peg$FAILED) {
s1 = [s1, s2];
s0 = s1;
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
}
}
return s0;
}
function peg$parseEOF() {
var s0, s1;
s0 = peg$currPos;
peg$silentFails++;
if (input.length > peg$currPos) {
s1 = input.charAt(peg$currPos);
peg$currPos++;
} else {
s1 = peg$FAILED;
Regenerate lib/parser.js after bytecode changes
10 years ago
if (peg$silentFails === 0) { peg$fail(peg$c34); }
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
peg$silentFails--;
if (s1 === peg$FAILED) {
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = void 0;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
} else {
peg$currPos = s0;
Regenerate lib/parser.js after bytecode changes
10 years ago
s0 = peg$FAILED;
PEG.js grammar: More JavaScript-like initializer/rule separation Initializer and rules are now separated in a similar way as JavaScript statements -- either by a semicolon or a line terminator, possibly with whitespace and comments mixed in. One consequence is that the grammars like this are now illegal: foo = "a" bar = "b" A semicolon needs to be inserted between the rules: foo = "a";bar = "b" I consider this a good change as the now-illegal syntax was somewhat confusing.
10 years ago
}
return s0;
}
Remove block around initialize code * In strict mode code, functions can only be declared at top level or immediately within another function. This means functions defined in the initializer would throw.
9 years ago
PEG.js grammar: Make rules with operators more generic
10 years ago
var OPS_TO_PREFIXED_TYPES = {
"$": "text",
"&": "simple_and",
"!": "simple_not"
};
var OPS_TO_SUFFIXED_TYPES = {
"?": "optional",
"*": "zero_or_more",
"+": "one_or_more"
};
var OPS_TO_SEMANTIC_PREDICATE_TYPES = {
"&": "semantic_and",
"!": "semantic_not"
};
PEG.js grammar: Fix line continuation handling in character classes Before this commit, line continuations in character classes contributed an empty string to the list of characters and character ranges matched by a class. While this didn't lead to a buggy behavior with the current code generator, the AST was wrong and the problem could have caused bugs later. This commit fixes the problem.
10 years ago
function filterEmptyStrings(array) {
var result = [], i;
for (i = 0; i < array.length; i++) {
if (array[i] !== "") {
result.push(array[i]);
}
}
return result;
}
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
function extractOptional(optional, index) {
return optional ? optional[index] : null;
}
function extractList(list, index) {
var result = new Array(list.length), i;
for (i = 0; i < list.length; i++) {
result[i] = list[i][index];
}
return result;
}
Switch from first/rest to head/tail in the PEG.js grammar In the past year I worked on various grammars where first/rest or head/tail were used as labels for parts of lists. I found I associate head/tail with a list immediately, while in case of first/rest I have to "parse" grammar rules for a while before understanding their structure. Moreover, I tend to assume that rest is a list of the same thigs as first, but I don't have such assumption in case of head/tail. This assumption was in conflict with the grammar structure. I'm not sure how much these observations are applicable to others, but I decided to act on them and switch from first/rest to head/tail.
9 years ago
function buildList(head, tail, index) {
return [head].concat(extractList(tail, index));
PEG.js grammar: Change whitespace handling Before this commit, whitespace was handled at the lexical level by making tokens consume any whitespace coming after them. This was accomplished by appending |__| to every token rule. This commit changes whitespace handling to be more explicit. Tokens no longer consume whitespace coming after them and syntactic rules have to cope with it. While this slightly complicates the syntactic grammar, I think it's a cleaner way. Moreover, it is what JavaScript example grammar does. One small side-effect of thich change is that the grammar is now stand-alone (it doesn't require utils.js anymore).
10 years ago
}
Remove block around initialize code * In strict mode code, functions can only be declared at top level or immediately within another function. This means functions defined in the initializer would throw.
9 years ago
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
peg$result = peg$startRuleFunction();
Error handling: Use a special value (not |null|) to indicate failure Using a special value to indicate match failure instead of |null| allows actions to return |null| as a regular value. This simplifies e.g. the JSON parser. Note the special value is internal and intentionally undocumented. This means that there is currently no official way how to trigger a match failure from an action. This is a temporary state which will be fixed soon. The negative performance impact (see below) is probably caused by changing lot of comparisons against |null| (which likely check the value against a fixed constant representing |null| in the interpreter) to comparisons against the special value (which likely check the value against another value in the interpreter). Implements part of #198. Speed impact ------------ Before: 1146.82 kB/s After: 1031.25 kB/s Difference: -10.08% Size impact ----------- Before: 950817 b After: 973269 b Difference: 2.36% (Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
11 years ago
if (peg$result !== peg$FAILED && peg$currPos === input.length) {
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
return peg$result;
} else {
Fix error messages in certain cases with trailing input In case the generated parser parsed successfully part of input and left some input unparsed (trailing input), the error message produced was sometimes wrong. The code worked correctly only if there were no match failures in the successfully parsed part (highly unlikely). This commit fixes things by explicitly triggering a match failure with the following expectation at the end of the successfully parsed part of the input: peg$fail({ type: "end", description: "end of input" }); This change also made it possible to simplify the |buildMessage| function, which can now ignore the case of no expectations. Fixes #119.
11 years ago
if (peg$result !== peg$FAILED && peg$currPos < input.length) {
peg$fail({ type: "end", description: "end of input" });
}
Improve location info in syntax errors Replace |line|, |column|, and |offset| properties of |SyntaxError| with the |location| property. It contains an object similar to the one returned by the |location| function available in action code: { start: { offset: 23, line: 5, column: 6 }, end: { offset: 25, line: 5, column: 8 } } For syntax errors produced in the middle of the input, |start| refers to the first unparsed character and |end| refers to the character behind it (meaning the span is 1 character). This corresponds to the portion of the input in the |found| property. For syntax errors produced the end of the input, both |start| and |end| refer to a character past the end of the input (meaning the span is 0 characters). For syntax errors produced by calling |expected| or |error| functions in action code the location info is the same as the |location| function would return.
9 years ago
throw peg$buildException(
null,
peg$maxFailExpected,
Remove info about found string from syntax errors The |found| property wasn't very useful as it mostly contained just one character or |null| (the exception being syntax errors triggered by |error| or |expected|). Similarly, the "but XXX found" part of the error message (based on the |found| property) wasn't much useful and was redundant in presence of location info. For these reasons, this commit removes the |found| property and corresponding part of the error message from syntax errors. It also modifies error location info slightly to cover a range of 0 characters, not 1 character (except when the error is triggered by |error| or |expected|). This corresponds more precisely to the actual situation. Fixes #372.
9 years ago
peg$computeLocation(peg$maxFailPos, peg$maxFailPos)
Improve location info in syntax errors Replace |line|, |column|, and |offset| properties of |SyntaxError| with the |location| property. It contains an object similar to the one returned by the |location| function available in action code: { start: { offset: 23, line: 5, column: 6 }, end: { offset: 25, line: 5, column: 8 } } For syntax errors produced in the middle of the input, |start| refers to the first unparsed character and |end| refers to the character behind it (meaning the span is 1 character). This corresponds to the portion of the input in the |found| property. For syntax errors produced the end of the input, both |start| and |end| refer to a character past the end of the input (meaning the span is 0 characters). For syntax errors produced by calling |expected| or |error| functions in action code the location info is the same as the |location| function would return.
9 years ago
);
Code generator rewrite This is a complete rewrite of the PEG.js code generator. Its goals are: 1. Allow optimizing the generated parser code for code size as well as for parsing speed. 2. Prepare ground for future optimizations and big features (like incremental parsing). 2. Replace the old template-based code-generation system with something more lightweight and flexible. 4. General code cleanup (structure, style, variable names, ...). New Architecture ---------------- The new code generator consists of two steps: * Bytecode generator -- produces bytecode for an abstract virtual machine * JavaScript generator -- produces JavaScript code based on the bytecode The abstract virtual machine is stack-based. Originally I wanted to make it register-based, but it turned out that all the code related to it would be more complex and the bytecode itself would be longer (because of explicit register specifications in instructions). The only downsides of the stack-based approach seem to be few small inefficiencies (see e.g. the |NIP| instruction), which seem to be insignificant. The new generator allows optimizing for parsing speed or code size (you can choose using the |optimize| option of the |PEG.buildParser| method or the --optimize/-o option on the command-line). When optimizing for size, the JavaScript generator emits the bytecode together with its constant table and a generic bytecode interpreter. Because the interpreter is small and the bytecode and constant table grow only slowly with size of the grammar, the resulting parser is also small. When optimizing for speed, the JavaScript generator just compiles the bytecode into JavaScript. The generated code is relatively efficient, so the resulting parser is fast. Internal Identifiers -------------------- As a small bonus, all internal identifiers visible to user code in the initializer, actions and predicates are prefixed by |peg$|. This lowers the chance that identifiers in user code will conflict with the ones from PEG.js. It also makes using any internals in user code ugly, which is a good thing. This solves GH-92. Performance ----------- The new code generator improved parsing speed and parser code size significantly. The generated parsers are now: * 39% faster when optimizing for speed * 69% smaller when optimizing for size (without minification) * 31% smaller when optimizing for size (with minification) (Parsing speed was measured using the |benchmark/run| script. Code size was measured by generating parsers for examples in the |examples| directory and adding up the file sizes. Minification was done by |uglify --ascii| in version 1.3.4.) Final Note ---------- This is just a beginning! The new code generator lays a foundation upon which many optimizations and improvements can (and will) be made. Stay tuned :-)
11 years ago
}
}
return {
Mark |parse| and |SyntaxError| as internal identifiers The |parse| function and the |SyntaxError| exception were meant as internal, so let's mark them as such.
10 years ago
SyntaxError: peg$SyntaxError,
parse: peg$parse
Bootstrapped the grammar parser, yay! I should have done this long ago.
14 years ago
};
UMD parsers: Regenerate lib/parser.js Part of work on #362.
8 years ago
});