3 ms·

PNaCl targets LLVM bitcode, so can be supported on any modern CPU: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http:/

PNaCl targets LLVM bitcode, so can be supported on any modern CPU: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test... Compiling other languages to JavaScript imposes an unacceptable speed penalty. C++-to-JavaScript is not a viable platform for real applications, especially anything performance-critical.

gsnedders 14y ago
Except, of course, LLVM bitcode isn't meant to be distributed: it's designed as a compiler IR, and merely an intermediary form. It's also not portable: the existence of types like x86_fp80 and ppc_fp128 make this quite clear.
- azakai 14y ago
  Yes, and it also implicitly includes assumptions on endianness, stack size, alignments, etc. It is very hard to make it portable. It's a great compiler IR though! This isn't a criticism of LLVM bitcode.
- haberman 14y ago
  I suggest reading the PNaCl paper, which addresses how they make LLVM bitcode distributable and portable. Because believe it or not, they have thought about these problems, and solutions to them have been designed and implemented. It's not a force-fit either. LLVM is designed to be a form from which machine-specific code is generated. The problem is only that different platforms have different conventions. But any modern 32-bit platform can use a given set of conventions if you want it to.
azakai 14y ago
See comments below - PNaCl is not finished, and we don't know what performance and portability it will provide when it is. It is also not close to being standardizable since it is in flux. Do you have numbers for the "unacceptable speed penalty" JavaScript imposes on compiled code? That's an honest question, I am curious to see benchmarks about that.