[nothrabannosir]

asm.js represents LLVM bytecode, which is already behind the compilation step. The programmer sees errors when generating the asm.js, not when executing it. Whether it is then executed by a JIT or not is, in this case, irrelevant.

I absolutely agree there are advantages to taking the asm.js -> LLVM bytecode shortcut (cue every single benchmark showing FF on top). But compiler warnings are not one of them.

EDIT: To clarify: my point is that this is not classical compilation, but rather "interpretation of the generated code". Nobody writes asm.js by hand, no matter how it is executed. If there are errors in there, there is something seriously wrong with the tooling, and when the errors show up will be the least of your worries. Comparable to errors in a .jar file or a .pyc---this is just not something we need to be generally concerned with.

EDIT2: I don't mind the downvotes but if I'm wrong, please explain so at least I understand. Otherwise I won't learn.

[jlongster]

I think I see what you are saying, but your statements aren't completely right which might be why you are being downvoted. "asm.js represents LLVM bytecode" is not right, just because you can compile one thing to another does not mean it represents it.

You make a good point though; it's not like we are seeing helpful warnings when writing our frontend JS apps. But those warnings are still crucial when actually building & deploying stuff; with various tooling and browsers it's really nice to see a "successful asm.js compilation" message and you know it's working. If you upgrade a tool, you can be sure that it's still working, etc.

Also, it's not uncommon for people to write new languages or compilers and having that feedback that you are on the fast path is really nice.

I think your point has some merit though.

The other benefit to AOT is simply that, when the app starts running, it immediately starts running in the fast path.

[nothrabannosir]

I see, you were not talking about errors, but about predictability of performance. I see it now in your comment, too. Sorry for the misunderstanding.

And I didn't know it was just derived from it; I thought asm.js was idempotent with llvm ir!

[pcwalton]

> And I didn't know it was just derived from it; I thought asm.js was idempotent with llvm ir!

LLVM IR is SSA and strongly typed, while asm.js is non-SSA and only has a simple, machine-level type system, just to name two large differences.

[reubenmorais]

You're misunderstanding jlongster's point, or putting too much emphasis on the compiler warning part.

When you load some asm.js code in Firefox and it compiles without errors or warnings, you then know for sure your code was fully compiled and you will not see parsing/compilation happening half-way through a game frame. This means it's slightly easier to reason about the performance of your code.

AFAIK, with the Chrome strategy, you have to think about JIT compilation kicking in at any point, which is unpredictable and completely out of your control.

[simcop2387]

It's likely because asm.js isn't at all related to LLVM. Emscripten and the like use LLVM IR to compile to asm.js but that doesn't mean that asm.js is LLVM IR. asm.js is actually just a restricted subset of javascript that avoids a lot of things that invoke the garbage collector, forces certain type constraints (variables have static types that can be inferred at parse/compile time), and emulation of pointers using a block of memory among a host of other things. LLVM just gets used the most because Emscripten makes for a really easy way to target the platform.

[TazeTSchnitzel]

Right, asm.js is basically a portable bytecode targeting a 32-bit virtual machine.

[TazeTSchnitzel]

> asm.js represents LLVM bytecode

No, emscripten compiles asm.js from LLVM IR, but asm.js itself is more like a portable bytecode for a 32-bit register machine.

> The programmer sees errors when generating the asm.js, not when executing it.

Why would that be the case? The point of asm.js is so browsers can optimise it. It doesn't matter what your tooling thinks, in the end what matters is whether browsers accept it.

> Whether it is then executed by a JIT or not is, in this case, irrelevant.

No, whether it is executed by a JIT is quite important. asm.js is a subset that browsers can validate and then compile ahead-of-time. If your code is failing validation and falling back to the usual JavaScript mode, there's a big performance penalty, and your code isn't asm.js-compliant!

> Nobody writes asm.js by hand, no matter how it is executed.

Actually, some people do. It's not the nicest of languages, but there are some people who do.

But even if you don't, what if you're using buggy or outdated tooling producing incorrect output? What if you're targeting a browser that doesn't support some new asm.js feature? You need to know if your code didn't validate!

[Sephr]

> Actually, some people do [write asm.js code by hand]

Who?

[s-macke]

I did for my emulator jor1k. Take a look:

https://github.com/s-macke/jor1k/blob/master/js/worker/or1k/...

Handwritten asm.js code. Around 10 hours or porting time.

[Sephr]

That's quite an impressive implementation! I didn't realize hand-written asm.js could be that readable.

[s-macke]

Yes, more or less. Every operation must be written, that the type is obvious for the compiler. And you have one array, the heap with some special index rules. For example: (r[((ins >> 9) & 0x7C)>>2]|0 The >>2 and |0 is necessary.

[TazeTSchnitzel]

People wanting high performance. For example, Grant Galitz's IodineGBA had some portions in asm.js https://github.com/taisel/IodineGBA

[Sephr]

No, it doesn't. Where in IodineGBA do you see any hand-written asm.js code?

Here's are some quotes from the author of that very library:

"asm.js requires a style of coding only compilers can output. A person writing actual asm.js code by hand would need to be insane as asm.js code required style of coding is horribly disorganized"[1]

"Unfortunately asm.js requires one giant array to put things on. No one in their right mind codes like that by hand."[2]

1: https://github.com/taisel/IodineGBA/issues/16#issuecomment-2... 2: https://github.com/taisel/IodineGBA/issues/16#issuecomment-2...

[TazeTSchnitzel]

That's from 2013. There have been more recent discussions.