<story><title>A New Bytecode Format for JavaScriptCore</title><url>https://webkit.org/blog/9329/a-new-bytecode-format-for-javascriptcore/</url></story><parent_chain><item><author>cogman10</author><text>I&amp;#x27;m unclear,  why transform to a bytecode as a first step? 
Wouldn&amp;#x27;t it be simpler to instead to transform to an AST and work against that for everything?  Wouldn&amp;#x27;t it make sense to generate the bytecode as sort of a last step before doing heavy duty optimizations?&lt;p&gt;Seems like with JS you would be constantly transforming from bytecode -&amp;gt; AST -&amp;gt; bytecode -&amp;gt; machine code, such as every time a method adds a new field to an object or some optimization assumption is violated.  It doesn&amp;#x27;t seem like it would be easier or faster to work with.  I&amp;#x27;m guessing there wouldn&amp;#x27;t be a whole lot of memory benefits either.&lt;p&gt;Would someone mind illuminating me on this design choice? (Granted, I&amp;#x27;ve not taken a compilers course, so feel free to call me an idiot for not knowing something basic about how compilers work).</text></item></parent_chain><comment><author>wahern</author><text>* Adding a new field or method to an object at runtime doesn&amp;#x27;t change the AST.&lt;p&gt;* You don&amp;#x27;t translate from bytecode to AST.&lt;p&gt;* In tiered JIT architectures--typical for dynamically-typed languages like JavaScript where as you point out effective types can mutate at runtime--most code is executed by an interpreter, not as compiled machine code.[1] Interpreters are more efficient when executing a bytecode than walking an AST.&lt;p&gt;* Translating an AST straight to machine code is much more difficult than translating a low-level intermediate representation, and such representations are often easy to express as simple bytecodes. Compilers like GCC and LLVM use intermediate representations: RTL and IR. Both are effectively assembly languages, and like all assembly languages trivial to express as bytecode. GCC also has GIMPLE, a higher-level intermediate representation earlier in the pipeline which expresses a generic AST. The fact that GIMPLE and RTL coexist drives home the point that you don&amp;#x27;t want to be translating tree-like representations straight to machine code.&lt;p&gt;* You don&amp;#x27;t need to take my word for this, or the word of anyone else. Every programmer should have experience writing parsers, compilers, and interpreters, regardless of whether they took a class or even went to university. By doing this most of the reasons for the way things are done will become immediately clear to you. Note that splitting strings with regular expressions does not count as parsing, not for these purposes. A good project, however, would be to write a regular expression parser, compiler, and interpreter. There are many examples to follow and you can copy their designs exactly; just don&amp;#x27;t copy+paste as actually going through the motions and understanding the complexities inherent in the implementations is how everything will become clear.&lt;p&gt;[1] How this mutation is handled and why tiered architectures are preferable is another topic entirely.</text></comment>
<story><title>A New Bytecode Format for JavaScriptCore</title><url>https://webkit.org/blog/9329/a-new-bytecode-format-for-javascriptcore/</url></story><parent_chain><item><author>cogman10</author><text>I&amp;#x27;m unclear,  why transform to a bytecode as a first step? 
Wouldn&amp;#x27;t it be simpler to instead to transform to an AST and work against that for everything?  Wouldn&amp;#x27;t it make sense to generate the bytecode as sort of a last step before doing heavy duty optimizations?&lt;p&gt;Seems like with JS you would be constantly transforming from bytecode -&amp;gt; AST -&amp;gt; bytecode -&amp;gt; machine code, such as every time a method adds a new field to an object or some optimization assumption is violated.  It doesn&amp;#x27;t seem like it would be easier or faster to work with.  I&amp;#x27;m guessing there wouldn&amp;#x27;t be a whole lot of memory benefits either.&lt;p&gt;Would someone mind illuminating me on this design choice? (Granted, I&amp;#x27;ve not taken a compilers course, so feel free to call me an idiot for not knowing something basic about how compilers work).</text></item></parent_chain><comment><author>pizlonator</author><text>AST is less transformable. We transform our bytecode as if it was just an IR.&lt;p&gt;ASTs are a pretty annoying form to use as a source of shared truth for OSR. JSC has 4 tiers so we need a convenient-to-use shared truth IR. That’s what bytecode is for. For example, bytecode offers high-scalability answers to questions like “where should I exit” and “what is live when I get there”.</text></comment>