Hacker News Reader

Comment by acqq | Hacker News Reader

In short: in order to write the fast interpreter for the bytecode of JavaScript in WebKit JS's JavaScriptCore, the author developed a custom variant of an assembly language, wrote the interpreter in it and wrote in Ruby the translator from his custom assembly to the native assembly (allowing him to target different processor architectures like x32 x64 and ARM, at least that's how I understood it from the description).

He explains how with C++ he could not get the speed gains he achieved with assembly. One real life example where writing exact assembly code still matters.

Coming to a browser near you.

View on HN

No offense intended, but this comment does not add very much while misunderstanding some other things. For example, I did not write the LLInt. It was mostly written by Apple's Filip Pizlo.

If this is the sort of topic you are interested in, then you can have the patience to read a few paragraphs. If it's not, then summarizing isn't going to help :)

Thanks, now I know that LLInt (the new interpreter) was written by Filip Pizlo. Note that you mention him in the article only related to DFG JIT. I didn't try to investigate the source files or checkins, I tried to understand only what you write, and that was obviously not clear enough.

I hope you see that I'm interested in the topic but read about it the first time. I hope you also can imagine that there are more readers like me. And they would benefit from the correct summary too.

Please do write what else I misunderstood, that is exactly the reason why I wrote the short summary, to get the feedback, not to claim that I understand more than you or any insider. It's short, counting the words some 20 times shorter than your article, so I hope it wouldn't be hard for you to point to any other inconsistency. Summarizing helps if the result is something relevant and clear, in a few sentences instead of 1700 words. Without the summary, the most important points can be overlooked/misunderstood by anybody not "close to the sources."

Well, I guess the one thing I would correct is the "why". The LLInt doesn't just produce assembler to be fast, though it is faster than the old interpreter. The real reason it produces assembler is to control the stack representation, so that it works better with tiering, exceptions, and the optimizing compiler (DFG). Otherwise, interpreting was a lose, because tiering up cost too much.

As you can see, the situation is a bit complicated. If I could have made the article shorter, I would have :)

Thanks, I understood that the main benefit was a tightly controlled CPU stack and that it's exactly what would be impossible to achieve with C++ code. Now we don't have to agree if that goal can be called "speed." I believe it can, since otherwise just a "good old" interpreter would be enough, no need for "simple JIT," DFG JIT and the control of the CPU stack.

And thanks for writing the article (and the other ones on the same subject) I've really learned a lot!

Reply on news.ycombinator.com