Jay Conrod

> The professional educator dialect of English is not very approachable for the layman.

I think Dan's blog is largely pitched at other professional educators. All professions develop their own technical vocabulary.

As an analogy, I recently enjoyed an article about the implementation of the v8 garbage collector by Jay Conrod: http://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection

Here's a sample paragraph:

"Distinguishing pointers and data on the heap is the first problem any garbage collector needs to solve. The GC needs to follow pointers in order to discover live objects. Most garbage collection algorithms can migrate objects from one part of memory to another (to reduce fragmentation and increase locality), so we also need to be able to rewrite pointers without disturbing plain old data."

I think the article is an excellent piece of technical writing, but it would also be reasonable to say "the professional compiler engineer dialect of English is not very approachable to the layman."

That said, good communicators need to be able to change their presentation based on the audience, and it's too bad that the people at the meeting you mention couldn't find a common vocabulary.

If you want to see something by the author of this post that is pitched at the layman, he made a very nice TedX presentation a few years ago:

http://www.ted.com/talks/dan_meyer_math_curriculum_makeover?language=en#t-202117

No, V8 parses your Javascript source into an AST. From the AST, there are two paths it can take. The first step is the "full-codegen" compiler, which walks the AST directly and emits unoptimized native code:

http://wingolog.org/archives/2011/07/05/v8-a-tale-of-two-compilers

If a function is hot, then it gets promoted to V8's optimizing compiler, which is currently Crankshaft but will soon be replaced by Turbofan. This compiles the AST first into a high-level IR, Hydrogen, which is an architecture-independent SSA-like form vaguely reminiscent of LLVM. Then that's lowered into an architecture-dependent IR, Lithium, where register allocation and instruction scheduling is performed.

http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-optimizing-compiler

If you read the bug for this that someone posted up-thread, the AST information is fully available when inlining in Hydrogen, but a patch to remove the character limit tanked one of their benchmarks. Also, they didn't preclude fixing it in Turbofan, only in Crankshaft, and that's largely because Crankshaft is on its way out.

(I've played a little with the internals of V8, but am not an official developer. Also, one of my friends is the Bay Area TL for V8.)

Sure, megamorphic code requires a JIT. But it's a trivial one so I don't count it. :) Essentially, if you have the expression:

z = x + y

If you statically can't know the types of x and y, you must do an expensive method lookup. You call some variant of the plus function if x and y are floats, another if they are strings or lists and so on. So a good runtime notes the types of x and y the first time the expression is evaluated and recompiles the expensive call to the general_add() function with, say if x and y are 32 bit ints, a quick add_32bit_ints() call.

See here for a description of the V8 JIT: http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-optimizing-compiler It appears to be just "a plain old compiler" with inlining of method lookups.

I've looked at yacc + bison a couple times and always turned away before even attempting to write parsers in them. It's ugly as hell and I figure sprinkling code is hard to understand and thus insecure.

However, have you tried parser combinators? Parsec (a Haskell library) is really nice if it fits your grammar.

Here is one guy who simulated that in Python, also very nice:

http://jayconrod.com/posts/37/