> NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86.
This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM.
> PNaCL is there to cover the case where we move past ARM and x86
That, too, but more importantly, it exists to let you run the same code (delivered as LLVM bitcode) on supported platforms, including x86 and ARM, instead of having to deliver separately-compiled code for each supported platform, as is the case for NaCl. That's what the "P" ("Portable") is about -- the code delivered runs on any PNaCl engine, unlike the case with NaCl where NaCl x86 code runs only on x86 and NaCl ARM code only on ARM.
You seem to have confused what PNaCl does now (experimental toolchain inside the NaCl SDK), and what the point of PNaCl is (to move the .pexe -> .nexe bitcode to native code piece of the toolchain from the SDK side into the client side, so all you deliver to the client is the platform-agnosti .pexe rather than the platform-specific .nexe.)
> This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM.
I didn't intend for this to be misleading -- the option to deploy code specific to each architecture is a benefit.
It means you can take advantage of the architecture's specific features (such as NEON and SSE).
> I didn't intend for this to be misleading -- running code specific to each architecture is a benefit.
Permitting it may be a benefit in some cases,
Being limited to it, as NaCl is until client-side PNaCl is ready, is a disadvantage.
Which is why Google is not enabling NaCl by default on the web (i.e., outside of the Chrome Web Store) until client-side PNaCl is ready -- they don't want needless proliferation of non-portable NaCl code on the web. And, I suspect, they want to make the .pexe-to-.nexe process as efficient, in terms of code generation, as possible, so as to minimize the scope of cases where specific-platform-targetting is necessary.
The phase that the web camp is in currently reminds me of a brief phase with Java in the 90's where everything was going to be rewritten on top of the JVM and all heterogeneity in computing stacks was going to disappear overnight.
This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM.
> PNaCL is there to cover the case where we move past ARM and x86
That, too, but more importantly, it exists to let you run the same code (delivered as LLVM bitcode) on supported platforms, including x86 and ARM, instead of having to deliver separately-compiled code for each supported platform, as is the case for NaCl. That's what the "P" ("Portable") is about -- the code delivered runs on any PNaCl engine, unlike the case with NaCl where NaCl x86 code runs only on x86 and NaCl ARM code only on ARM.
You seem to have confused what PNaCl does now (experimental toolchain inside the NaCl SDK), and what the point of PNaCl is (to move the .pexe -> .nexe bitcode to native code piece of the toolchain from the SDK side into the client side, so all you deliver to the client is the platform-agnosti .pexe rather than the platform-specific .nexe.)