4 ms·

I AM using the same yardstick (neither asm.js nor PNaCl is usable today if you want the things I listed, but I predict PNaCl will exist in some form sooner), an

I AM using the same yardstick (neither asm.js nor PNaCl is usable today if you want the things I listed, but I predict PNaCl will exist in some form sooner), and I'm asking you to at least talk about the merits of PNaCl. Instead of constantly beating the JavaScript drum, you could have instead said "We have tried to work with Google to standardize PNaCl without Pepper and they are not open to discussion." I know you have objections to Pepper, and I don't disagree, but personally I would be happy with a PNaCl minus Pepper too. Make WebIDL accessible from PNaCl and we can ignore all of the API issues. I have a great deal of respect for you, Brendan, and Mozilla, and this is purely a communication tone issue, but as a game developer, it frequently sounds like Mozilla is more interested in the purity of the web than actually solving developer use cases. In fact, I had a couple discussions with game developers just yesterday about the fact that it feels like Google cares more. HOWEVER, asm.js, parts of ES6/7, WebGL, etc. go a long way towards meeting the needs of game developers, so I know you actually do care about solving use cases. But you could at least be more respectful of Google's direct approach.

pcwalton 14y ago
Personally, as someone who works with LLVM IR on a daily basis, the idea of standardizing LLVM IR as it exists today worries me a lot for several reasons: * Most importantly: LLVM IR is a compiler IR. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... * LLVM IR is really big compared to asm.js. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... * LLVM IR wasn't really designed to be portable. clang bakes lots of architecture-specific stuff into the IR that it generates. It can be hacked around the way PNaCl does by trying to define a "generic" architecture, but it's stretching the architecture beyond what it was intended to do. * LLVM IR is very unstable and continually changes from version to version. If we don't care about backwards compatibility, I would much rather see a bytecode standard done from scratch than PNaCl's approach of trying to use LLVM IR. I know the reason they did it is to use LLVM's code generation backends, but I feel like that could be done without using a large underspecified compiler IR as the transport format.
BrendanEich 14y ago
Sorry, it was you, not me, who shifted the topic from "merit" to "doesn't work cross-browser". I called that out because I'm pretty sure int64 and uint64, along with SIMD intrinsics, are coming to cross-browser JS -- while NaCl and PNaCl and in particular Pepper are not going cross-browser. If you want to stick to merit-only arguments, please don't knock int64 as Mozilla-only or we'll circle back to the relative odds of JS standards evolving vs. infeasibility of standardizing Pepper + *NaCl. On tone, I hope the above makes clear why I responded to your "not in other browsers" comment. On purity, Mozilla has been faulted for being impure forever (not GPL, not XML/XHTML, not forsaking the average mass-market user for elite developers, etc. etc.). Our asm.js work is fully pragmatic and our talk at GDC (sorry it overlapped yours) had exactly the right tone. We are here to help game devs, without any purity tax. On NaCl (not PNaCl) minus Pepper, I think we agree. We're looking at zerovm and similar uses of SFI in the context of the Servo project, for safer native code. That is where NaCl really shines, IMHO: safer native and OS/CPU-targeted code in native apps. It would be a shame if NaCl doesn't cater to this better use-case and instead tilts at the PNaCl cross-browser windmill. /be

pcwalton 14y ago

Personally, as someone who works with LLVM IR on a daily basis, the idea of standardizing LLVM IR as it exists today worries me a lot for several reasons: * Most importantly: LLVM IR is a compiler IR. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... * LLVM IR is really big compared to asm.js. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... * LLVM IR wasn't really designed to be portable. clang bakes lots of architecture-specific stuff into the IR that it generates. It can be hacked around the way PNaCl does by trying to define a "generic" architecture, but it's stretching the architecture beyond what it was intended to do. * LLVM IR is very unstable and continually changes from version to version. If we don't care about backwards compatibility, I would much rather see a bytecode standard done from scratch than PNaCl's approach of trying to use LLVM IR. I know the reason they did it is to use LLVM's code generation backends, but I feel like that could be done without using a large underspecified compiler IR as the transport format.

BrendanEich 14y ago

Sorry, it was you, not me, who shifted the topic from "merit" to "doesn't work cross-browser". I called that out because I'm pretty sure int64 and uint64, along with SIMD intrinsics, are coming to cross-browser JS -- while NaCl and PNaCl and in particular Pepper are not going cross-browser. If you want to stick to merit-only arguments, please don't knock int64 as Mozilla-only or we'll circle back to the relative odds of JS standards evolving vs. infeasibility of standardizing Pepper + *NaCl. On tone, I hope the above makes clear why I responded to your "not in other browsers" comment. On purity, Mozilla has been faulted for being impure forever (not GPL, not XML/XHTML, not forsaking the average mass-market user for elite developers, etc. etc.). Our asm.js work is fully pragmatic and our talk at GDC (sorry it overlapped yours) had exactly the right tone. We are here to help game devs, without any purity tax. On NaCl (not PNaCl) minus Pepper, I think we agree. We're looking at zerovm and similar uses of SFI in the context of the Servo project, for safer native code. That is where NaCl really shines, IMHO: safer native and OS/CPU-targeted code in native apps. It would be a shame if NaCl doesn't cater to this better use-case and instead tilts at the PNaCl cross-browser windmill. /be