Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Native Client 0.5 : released with stable ABI

code.google.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Google Native Client 0.5 : released with stable ABI

#11

Post by forgotusername »

haberman wrote: post #10
forgotusername wrote: post #7

Earlier quoted context omitted.

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…

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…

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).

Re: Google Native Client 0.5 : released with stable ABI

#14

Post by ysangkok »

forgotusername wrote: post #11
haberman wrote: post #10

Earlier quoted context omitted.

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…

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.

Re: Google Native Client 0.5 : released with stable ABI

#16

Post by majmun »

morganpyne wrote: post #2

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 ou…

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.

Re: Google Native Client 0.5 : released with stable ABI

#17

Post by nextparadigms »

haberman wrote: post #10
forgotusername wrote: post #7

Earlier quoted context omitted.

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…

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…

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).

Re: Google Native Client 0.5 : released with stable ABI

#18

Post by wladimir »

forgotusername wrote: post #7
morganpyne wrote: post #4

Earlier quoted context omitted.

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…

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)

Re: Google Native Client 0.5 : released with stable ABI

#19

Post by kayoone »

ysangkok wrote: post #13
kayoone wrote: post #12

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.
Post reply on HN