Google Native Client 0.5 : released with stable ABI(code.google.com)
code.google.com
Google Native Client 0.5 : released with stable ABI
http://code.google.com/intl/el-GR/chrome/nativeclient/docs/releasenotes.html
18 comments
NaCl seems like such a dead end, I can't understand why work is going into this instead of PNaCl.
Could you explain this a little more? I have no real knowledge of either and would be curious to hear your opinion as to which one may have a future and why.
The basic complaint is that NaCl is architecturally tied to 32bit x86. It relies on segmentation (bounds) checking that no longer exists on amd64, and perhaps more damningly, it's tied to the Intel instruction set altogether.
PNaCl is basically the same idea but built on top of LLVM's bitcode format (sortof a portable "high level assembly" representation of a program).
Personally except for the segmentation issue, I don't see bitcode as particularly compelling over x86, since the latter is already ubiquitous, and the other major issue with x86 that'd prevent efficient use on other platforms, that of instruction alignment, is already expressly prohibited in NaCl (in other words it should be easily possible to statically translate an x86 NaCl executable to run on ARM or similar, without all the overhead of runtime translation e.g. VMware). I'm guessing at least some of this kind of translation is already done even on amd64 in order to support bounds checking from software.
Edit: disclaimer: I've never actually used it, just found it intensely interesting when it was first released. These days I tend to think of it as just another Google land-grab involving a non-portable API that backs onto some "trusted" service with only a single provider at present (kinda like App Engine). From reading the Chromium roadmap (they someday hope Chromium will itself mostly run underneath NaCl), seems that's very much what they want it to be in the long term.
PNaCl is basically the same idea but built on top of LLVM's bitcode format (sortof a portable "high level assembly" representation of a program).
Personally except for the segmentation issue, I don't see bitcode as particularly compelling over x86, since the latter is already ubiquitous, and the other major issue with x86 that'd prevent efficient use on other platforms, that of instruction alignment, is already expressly prohibited in NaCl (in other words it should be easily possible to statically translate an x86 NaCl executable to run on ARM or similar, without all the overhead of runtime translation e.g. VMware). I'm guessing at least some of this kind of translation is already done even on amd64 in order to support bounds checking from software.
Edit: disclaimer: I've never actually used it, just found it intensely interesting when it was first released. These days I tend to think of it as just another Google land-grab involving a non-portable API that backs onto some "trusted" service with only a single provider at present (kinda like App Engine). From reading the Chromium roadmap (they someday hope Chromium will itself mostly run underneath NaCl), seems that's very much what they want it to be in the long term.
NativeClient supports ARM (http://www.h-online.com/open/news/item/Google-s-Native-Clien...).
You would have to compile multiple versions to support multiple architectures, but the implication that NaCl is fundamentally tied to x86 is incorrect.
NativeClient's use of segmentation on x86 is just an implementation detail of how the sandbox is implemented on that architecture, AFAIK. NaCl doesn't fundamentally require that any target architecture support segmentation.
You would have to compile multiple versions to support multiple architectures, but the implication that NaCl is fundamentally tied to x86 is incorrect.
NativeClient's use of segmentation on x86 is just an implementation detail of how the sandbox is implemented on that architecture, AFAIK. NaCl doesn't fundamentally require that any target architecture support segmentation.
It better have very strong support for ARM, too. It already bugs me that Google wants to use Intel chips so much for some of their products, that they end up making them too expensive, and as such a failure in the market. See Google TV, and now even Chromebooks (which should've been much cheaper).
If they would've started off directly with ARM chips, they wouldn't have had the same problem, because the products would've been priced more reasonably (unless manufacturers wanted to put the "early adopter tax" on them, too).
If they would've started off directly with ARM chips, they wouldn't have had the same problem, because the products would've been priced more reasonably (unless manufacturers wanted to put the "early adopter tax" on them, too).
Yep sorry for the misinformation, I hadn't read much about it recently. Seems whatever it does on amd64 (or in PNaCl at a guess) is also how it works on arm (7% slowdown from looking at the FAQ).
It's called Software Fault Isolation. There is a link to the paper on it in Wikipedia.
Thanks for the information. I did a little googling also after posting my question and it seems that it would be foolish to look at using either of them for any sort of production code at the moment. I think the PNaCl approach looks more interesting though. One to watch perhaps, but more out of curiosity right now.
X86 is not very well suited as platform-independent code, as the instruction set is way too complex and convoluted to allow for efficient emulation / translation. ARM assembly might qualify for this, though I'd personally prefer PNaCl as it is completely platform-agnostic.
(and anyway, why would you even want to translate from X86 to other architectures when translation from bitcode is already implemented and well-tested in LLVM)
(and anyway, why would you even want to translate from X86 to other architectures when translation from bitcode is already implemented and well-tested in LLVM)
Much of the recent work appears to be on APIs and browser integration, which I assume would be shared with pNaCl.
Does anybody here have experience using this? It looks like it could potentially solve an issue for me bridging access to USB and TCP-accessible devices from a cross-platform browser-based app, while giving a relatively easy way to get the software installed on them. On the other hand, will this turn out to be the DirectX of the future (ugh). Would love to hear some personal anecdotes from someone who was tried it out.
NaCl can perform the same I/O that JavaScript can, so it may not do what you want.
Thanks for the reply. If it's limited to what JS can do it certainly won't do what I need. Also just noticed I wrote "DirectX" instead of "ActiveX" in my previous post, oops.
this is what is missing in all modern browsers, browser is envisioned from start as a client and therefore not able to access such things. But i agree there sholud be browser with JS and all that with capabilities of server behaviour.
maybe next gen of browsers will have that. allthou it could brake the concept of thin clients.
So when is this integrated into Chrome then ? Is it already? I cant really find information on that.
It already is. You need to enable it manually though. If you use NaCl 0.5 you need Chrome 14.
Alright cool, but when is it enabled by default so we can take advantage of users not needing a plugin anymore ? Does google have any plan there ? Seems to take forever since i first read about NaCL in 2009.
Its crashing at my end.