Bringing Asm.js to Chakra and Microsoft Edge

Post by teacup50 » Thu, May 07, 2015, 8:48 PM UTC

pcwalton wrote: post #31

WorldWideWayne wrote: post #10

Earlier quoted context omitted.

I want less things emulated via Javascript and more stuff done directly via native code. Everything that is built on top of HTML/JS/CSS is basically a hack that is trying to emulate much better native platforms and it sucks. Why advocate to stay there? Let's go in the other direction in my opinion.

The choice isn't between "support HTML/CSS/JS" and "don't support HTML/CSS/JS". No Web browser can drop backwards compatibility. We haven't even been able to get rid of backwards compatibility for much worse things than CSS, such as , because sites you need to use (such as Hacker News) won't update their markup to use CSS for layout. asm.js is attractive because it is a small extension to the Web platform, so the ove…

Post by sp332 » Thu, May 07, 2015, 9:15 PM UTC

Siecje wrote: post #42

dicroce wrote: post #2

Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....

What does Google need to do to support asm.js? I thought asm.js is a subset of JavaScript so shouldn't it already be supported?

Post by Sephr » Thu, May 07, 2015, 9:16 PM UTC

TazeTSchnitzel wrote: post #18

flohofwoe wrote: post #12

Earlier quoted context omitted.

In the end there's not much difference between PNaCl and asm.js (see for yourself: http://floooh.github.io/oryol/ ). Both compile down to 'immutable' machine code, either via JIT or AOT compilation, both call into the same browser API backends, both are based on LLVM (actually PNaCl and emscripten use the same modified LLVM frontend) both have somewhat similar restrictions what APIs can be called in threads, the only…

There's a very big difference. NaCl and PNaCl don't use the standard, multi-vendor web APIs. They use a proprietary single-vendor (Google) API, Pepper. This not only makes implementation by competitors difficult, it's needless duplication of effort (why maintain multiple APIs for the same thing?). Also, both are based on single-vendor, single-implementation technology. NaCl used actual native code, so if you're not u…

Post by Sephr » Thu, May 07, 2015, 9:21 PM UTC

TazeTSchnitzel wrote: post #16

nothrabannosir wrote: post #11

Earlier quoted context omitted.

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 cl…

> 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.…

Post by drawkbox » Thu, May 07, 2015, 9:36 PM UTC

dicroce wrote: post #2

Come on Google! Support asm.js in Chrome.... Give up on Native Client.... Even Microsoft is doing Asm.js now....