4 ms·

It's assembly language the same way LLVM bitcode is assembly langauge, which means IT ISN'T. It is also represented in text, which means that it is several time

It's assembly language the same way LLVM bitcode is assembly langauge, which means IT ISN'T. It is also represented in text, which means that it is several times larger than it needs to be. Another problem with Asm.js in practice is that it's used with Emscripten which doesn't define the syscalls you talk about. All the DOM/WebAudio/WebRTC/etc API's have to be redone in Emscripten's headers. GL was easy, because WebGL is so close to EGL and friends. But what about DOM manipulation? Emscripten can't really do this yet. These two disadvantages happen to be problems solved in PNaCl, which has a compact bitcode (which doesn't pretend to be JavaScript) and a proper API (Pepper).

acjohnson55 13y ago
The fact that asm.js is represented in text does not make it unlike assembly language. It makes it unlike bit/bytecode or machine code.
- jheriko 13y ago
  assembly is just mnemonics for the machine code - that is very important to remember. its a different encoding, but its one which has a strong and tightly coupled relationship to the point where disassemblers are a thing.. sure asm.js is encoded as text, but its not encoding anything close to what assembly languages do.
  - acjohnson55 13y ago
    I have another reply to that effect somewhere in this thread :) Modern assembly languages often at a slightly higher level of representation than 1-to-1 with the instruction set so it's tough to draw a tough line, but yes, generally speaking, you should be able to translate the majority of the language to machine code with opcode tables. It's also interesting that machine code isn't even the lowest level representation of machine instructions on many architectures, which internally use microcode to implement architectural instructions. My point was that LLVM bitcode and asm.js are both intermediate targets, but not exactly the same.
    - jheriko 13y ago
      You mean macro assembler languages? Its a pedantic distinction but I wasn't intending to imply those... 'Pure' assembly languages are still not 1 to 1 but are never worse than many to one, eg nop is often a real, but useless instruction with some other mnemonic.... Not sure what you point is about microcode... That is an implementation detail which, even for eg, x86 LEA where you think you are leveraging it, it is not important or useful beyond trying to understand performance characteristics. What you get to work with is whole instructions.
      - acjohnson55 13y ago
        We agree! I'm not arguing with you. I'm just trying to provide a bit more context for people who are trying to understand the purpose of all this. Judging by the vast majority of remarks on the article, there's a lot of misunderstanding of how this stuff works.
adamtj 13y ago
You are technically correct - the best kind of correct! While I was being a bit loose with my language, I don't think that changes the point. So maybe it's not an assembly language or a bytecode, but that's a pretty unimportant distinction. Those are all intermediate representations (IR). A good browser will JIT your asm.js IR to machine code in much the same way that a good JVM will JIT your bytecode. An old browser will interpret it more slowly, but it will still work. Asm.js may be crappy at the moment, but it will get better. It's an easily JITtable IR for the web that's already supported in all browsers, even the old ones. And the security is basically free since that's already being paid for. Yes, it's a bloated text encoding, but gzip is pretty effective. No, it doesn't have great compiler support yet, but Emscripten and equivalent will no doubt have lots of useful headers and emulation and translation libraries very soon. Asm.js is going to win for the same reason that Javascript won: everybody already has it.
- espadrine 13y ago
  Nitpick: asm.js is designed for AOT, not JIT, compilation. A good browser will AOT asm.js, not JIT it. (In other words: pre-compiled, not compiled on the fly. Consequence: immediately as fast as a JIT would have… eventually… made it, but initial pause while compiling.)
jdlshore 13y ago
> It is also represented in text, which means that it is several times larger than it needs to be. According to the emscripten FAQ[1], gzipped emscriptem output (which uses asm.js) is about the same size as gzipped native code. [1] https://github.com/kripken/emscripten/wiki/FAQ https://github.com/kripken/emscripten/wiki/FAQ

acjohnson55 13y ago

The fact that asm.js is represented in text does not make it unlike assembly language. It makes it unlike bit/bytecode or machine code.

jheriko 13y ago
assembly is just mnemonics for the machine code - that is very important to remember. its a different encoding, but its one which has a strong and tightly coupled relationship to the point where disassemblers are a thing.. sure asm.js is encoded as text, but its not encoding anything close to what assembly languages do.
- acjohnson55 13y ago
  I have another reply to that effect somewhere in this thread :) Modern assembly languages often at a slightly higher level of representation than 1-to-1 with the instruction set so it's tough to draw a tough line, but yes, generally speaking, you should be able to translate the majority of the language to machine code with opcode tables. It's also interesting that machine code isn't even the lowest level representation of machine instructions on many architectures, which internally use microcode to implement architectural instructions. My point was that LLVM bitcode and asm.js are both intermediate targets, but not exactly the same.
  - jheriko 13y ago
    You mean macro assembler languages? Its a pedantic distinction but I wasn't intending to imply those... 'Pure' assembly languages are still not 1 to 1 but are never worse than many to one, eg nop is often a real, but useless instruction with some other mnemonic.... Not sure what you point is about microcode... That is an implementation detail which, even for eg, x86 LEA where you think you are leveraging it, it is not important or useful beyond trying to understand performance characteristics. What you get to work with is whole instructions.
    - acjohnson55 13y ago
      We agree! I'm not arguing with you. I'm just trying to provide a bit more context for people who are trying to understand the purpose of all this. Judging by the vast majority of remarks on the article, there's a lot of misunderstanding of how this stuff works.

adamtj 13y ago

You are technically correct - the best kind of correct! While I was being a bit loose with my language, I don't think that changes the point. So maybe it's not an assembly language or a bytecode, but that's a pretty unimportant distinction. Those are all intermediate representations (IR). A good browser will JIT your asm.js IR to machine code in much the same way that a good JVM will JIT your bytecode. An old browser will interpret it more slowly, but it will still work. Asm.js may be crappy at the moment, but it will get better. It's an easily JITtable IR for the web that's already supported in all browsers, even the old ones. And the security is basically free since that's already being paid for. Yes, it's a bloated text encoding, but gzip is pretty effective. No, it doesn't have great compiler support yet, but Emscripten and equivalent will no doubt have lots of useful headers and emulation and translation libraries very soon. Asm.js is going to win for the same reason that Javascript won: everybody already has it.

espadrine 13y ago
Nitpick: asm.js is designed for AOT, not JIT, compilation. A good browser will AOT asm.js, not JIT it. (In other words: pre-compiled, not compiled on the fly. Consequence: immediately as fast as a JIT would have… eventually… made it, but initial pause while compiling.)

jdlshore 13y ago

> It is also represented in text, which means that it is several times larger than it needs to be. According to the emscripten FAQ[1], gzipped emscriptem output (which uses asm.js) is about the same size as gzipped native code. [1] https://github.com/kripken/emscripten/wiki/FAQ https://github.com/kripken/emscripten/wiki/FAQ