4 ms·

asm.js is untyped, unlike LLVM bitcode Is that really true? The way I read the spec was that asm.js was all about adding type annotations to JavaScript in a ba

asm.js is untyped, unlike LLVM bitcode Is that really true? The way I read the spec was that asm.js was all about adding type annotations to JavaScript in a backwards-compatible way. And just thinking logically, it's hard to imagine asm.js optimizing anything beyond what JS is already doing without explicit type annotations – and we already know asm.js gives insane speed increases with a compiler that understands the type annotations.

pcwalton 14y ago
There are degrees of typed-ness. :) What I mean to say is that asm.js has a much weaker type system—in particular, asm.js does not have aggregate or structural types. The only types are numerics. This is in contrast to LLVM's type system, which features structs, arrays, and so forth. This gives the LLVM compiler much more information for important optimizations such as scalar replacement of aggregates, but those optimizations are typically done before asm.js emission.
- munificent 14y ago
  > in particular, asm.js does not have aggregate or structural types. It's like BCPL!
  - pcwalton 14y ago
    This is a feature, not a drawback. Aggregate types for C-like languages tend to bloat the code for no real optimization benefit. See the comparison between LLVM IR and Emscripten-generated JavaScript here: http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... (Of course, for GC'd languages, we will need aggregate types.)
    - DannyBee 14y ago
      Actually, aggregate types help optimization a lot in C like languages, because it makes it easy to disambiguate between accesses based on offsets. IE two random int pointers is not helpful, two accesses to fields through a pointer to a structure is helpful. In non-pointer C like languages, yes, they are mostly a burden. The reason the .bc in the example given is large is because the toolchain does not try to optimize at all for intermediate .bc size. Final .bc size should be relatively sane. I don't see that I can download the .bc files from that blog post, but I'm mildly curious if they are before or after running opt, because if i had to guess, based on the fact that it gzip's well, i'd guess it's before running opt on it.
      - pcwalton 14y ago
        Sorry, I should have been clearer: the types are definitely helpful for optimization. For distribution I'm not so sure. The IR-level optimizations where types really help (scalar replacement of aggregates, etc) are already run before the code hits the wire.
        DannyBee 14y ago
        It depends. For distribution where you know you will never optimize at runtime, yes, it's completely worthless. But part of the reason you may find it worthless is because none of these VM's really perform the strong alias analysis and load/store redundancy removal techniques you could perform at runtime.
    - BruceM 14y ago
      > (Of course, for GC'd languages, we will need aggregate types.) Maybe, maybe not. I've had parts of a precise, copying, compacting (commercial grade) garbage collector running under emscripten. It "crashes" still, but seems viable.
  - stormbrew 14y ago
    Oh man, I'm so tempted to write a BCPL compiler for asm.js now.
    - hermanhermitage 14y ago
      Martin Richards compiler is pretty easy to add a backend to. I got the distribution he covers in his BCPL for young people (raspberrypi) guide. I targeted VideoCore for some tinkering I was doing, asm.js sould be fairly easy - just the relooping stuff would be the main effort. Would be interesting to see Martin Richards classic benchmark compiled to asm.js from BCPL and compared with the port to js.
  - backspaces 14y ago
    +1 BCPL! Like the first language after it was B. Then C. So shouldn't C++ be P? :)

pcwalton 14y ago

There are degrees of typed-ness. :) What I mean to say is that asm.js has a much weaker type system—in particular, asm.js does not have aggregate or structural types. The only types are numerics. This is in contrast to LLVM's type system, which features structs, arrays, and so forth. This gives the LLVM compiler much more information for important optimizations such as scalar replacement of aggregates, but those optimizations are typically done before asm.js emission.

munificent 14y ago
> in particular, asm.js does not have aggregate or structural types. It's like BCPL!
- pcwalton 14y ago
  This is a feature, not a drawback. Aggregate types for C-like languages tend to bloat the code for no real optimization benefit. See the comparison between LLVM IR and Emscripten-generated JavaScript here: http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... (Of course, for GC'd languages, we will need aggregate types.)
  - DannyBee 14y ago
    Actually, aggregate types help optimization a lot in C like languages, because it makes it easy to disambiguate between accesses based on offsets. IE two random int pointers is not helpful, two accesses to fields through a pointer to a structure is helpful. In non-pointer C like languages, yes, they are mostly a burden. The reason the .bc in the example given is large is because the toolchain does not try to optimize at all for intermediate .bc size. Final .bc size should be relatively sane. I don't see that I can download the .bc files from that blog post, but I'm mildly curious if they are before or after running opt, because if i had to guess, based on the fact that it gzip's well, i'd guess it's before running opt on it.
    - pcwalton 14y ago
      Sorry, I should have been clearer: the types are definitely helpful for optimization. For distribution I'm not so sure. The IR-level optimizations where types really help (scalar replacement of aggregates, etc) are already run before the code hits the wire.
      - DannyBee 14y ago
        It depends. For distribution where you know you will never optimize at runtime, yes, it's completely worthless. But part of the reason you may find it worthless is because none of these VM's really perform the strong alias analysis and load/store redundancy removal techniques you could perform at runtime.
  - BruceM 14y ago
    > (Of course, for GC'd languages, we will need aggregate types.) Maybe, maybe not. I've had parts of a precise, copying, compacting (commercial grade) garbage collector running under emscripten. It "crashes" still, but seems viable.
- stormbrew 14y ago
  Oh man, I'm so tempted to write a BCPL compiler for asm.js now.
  - hermanhermitage 14y ago
    Martin Richards compiler is pretty easy to add a backend to. I got the distribution he covers in his BCPL for young people (raspberrypi) guide. I targeted VideoCore for some tinkering I was doing, asm.js sould be fairly easy - just the relooping stuff would be the main effort. Would be interesting to see Martin Richards classic benchmark compiled to asm.js from BCPL and compared with the port to js.
- backspaces 14y ago
  +1 BCPL! Like the first language after it was B. Then C. So shouldn't C++ be P? :)