The terminology in the article is somewhat idiomatic: "After the Directed Flow Graph (DFG) or syntax tree has been generated the compiler can use this knowledge to perform further optimisations prior to the generation of machine code. Mozilla’s IonMonkey and Google’s Crankshaft are examples of these DFG compiler."<p>"DFG" usually refers to some sort of dependence graph. What IonMonkey and Crankshaft have is a traditional CFG (control flow graph) in SSA form. That means the code is represented as a set of straight line code paths (basic blocks) connected edges in a graph representing possible control-flow transitions. The instructions are in SSA form, which means that each variable is assigned only once and pseudo-instructions called "phi instructions" are used to merge results when a basic block is accessible from multiple predecessors blocks, both of which might assign the same variable. A "syntax tree" is different yet. It's a higher level representation that preserves the syntactic structure of the code. For example, it represents loops and "if" statements as nested elements in the tree. Translation to a CFG throws away most of that information (e.g. reducing loops to simply control flow edges in the CFG).<p>For a (relatively) approachable set of materials on the subject, see: <a href="http://www.cs.rice.edu/~keith/512/2011/Lectures" rel="nofollow">http://www.cs.rice.edu/~keith/512/2011/Lectures</a>. I also highly recommend Cooper & Torczon's "Engineering a Compiler" (2d Ed.) In a world of CS researchers that can't write an English sentence to save their lives, Keith Cooper and Linda Torczon's work is a paragon of clear prose. (Their lab at Rice is where Cliff Click got his PhD, and if you've read his work on the JVM, you know that he too has a talent for explaining complicated concepts in plain English.)
The 4 parts:<p>- The JavaScript family tree: <a href="http://creativejs.com/2013/06/the-race-for-speed-part-1-the-javascript-engine-family-tree&#x2F" rel="nofollow">http://creativejs.com/2013/06/the-race-for-speed-part-1-the-...</a>;<p>- How compilers work: <a href="http://creativejs.com/2013/06/the-race-for-speed-part-2-how-javascript-compilers-work&#x2F" rel="nofollow">http://creativejs.com/2013/06/the-race-for-speed-part-2-how-...</a>;<p>- JavaScript compiler strategies: <a href="http://creativejs.com/2013/06/the-race-for-speed-part-3-javascript-compiler-strategies&#x2F" rel="nofollow">http://creativejs.com/2013/06/the-race-for-speed-part-3-java...</a>;<p>- The future for JavaScript: <a href="http://creativejs.com/2013/06/the-race-for-speed-part-4-the-future-for-javascript&#x2F" rel="nofollow">http://creativejs.com/2013/06/the-race-for-speed-part-4-the-...</a>;
Source for a JavaScript compiler implemented in the D programming language:<p><a href="https://github.com/DigitalMars/DMDScript" rel="nofollow">https://github.com/DigitalMars/DMDScript</a>
So I have question I'm sure someone here is smart enough to answer- simply put, does ASI affect compilation speed?<p>In my head I would imagine that a compiler would expect to find semicolons as statement terminators but would have to reprocess a block if validation failed and try to figure out where the semicolons should be, and therefore ASI would slow down compilation (vs a file with all semicolons in place).
A very nice text with the nice code examples is:<p><a href="http://mrale.ph/blog/2012/06/03/explaining-js-vms-in-js-inline-caches.html" rel="nofollow">http://mrale.ph/blog/2012/06/03/explaining-js-vms-in-js-inli...</a>