Google extends ARM to browser natives

Native Client plug-in goes portable

By Cade Metz, 18th March 2010

Google has told the world that Native Client - its native-code browser plug-in - can now run on ARM chips.

When the plug-in was first released a year ago, it only ran on x86 processors, but the company has now updated the platform for x86-64 and ARM. In a blog post, Google said that its initial tests indicate that on both chips, a Native Client executable runs at about 97 per cent of the speed of unmodified native code. "These results indicate that a browser running on virtually any modern computer or cell phone could run a fast, performance-sensitive Native Client application," the company says.

Google doesn't like other peoples' plug-ins - contraptions like Adobe's Flash and Microsoft's Silverlight - but it has high hopes for Native Client, aka NaCl. When it unveiled early code for Chrome OS in the fall, the company said that Native Client would be an "important part" of an effort to boost the performance of applications running on its browser-based "operating system".

Chrome OS is set to arrive in the fall on x86 and, yes, ARM netbooks. Google first unveiled Native Client in December 2008, calling it "a technology that aims to give web developers access to the full power of the client's CPU while maintaining the browser neutrality, OS portability, and safety that people expect from web applications". Then, in October of last year, it slipped the plug-in into its Chrome browser, which serves as the centerpiece for Chrome OS. The OS is essentially Chrome running atop the company's Goobuntu flavor of Linux.

NaCl

"We are investing a lot in additional technologies like Native Client, which will make it really possible for some of the most performance-intensive desktop applications to become web applications," VP of Product Management Sundar Pichai said when the early Chrome OS was unveiled.

In addition to Linux, Native Client runs on Mac and Windows.

With its blog post yesterday, Google also announced that it's developing a means of distributing portable versions of Native Code executables across all processors. "We recognize that just running on today’s most popular architectures isn’t enough; if a new processor architecture emerges, it should be able to run all Native Client modules already released without requiring developers to recompile their code," the company says.

"Using this technology, a browser running on any type of processor could translate the portable representation into a native binary without access to the source code of the program."

This Portable Native Client project - aka PNaCl, pronounced 'pinnacle' - uses the Low-level Virtual Machine (LLVM) bitcode format. Essentially, you can compile C, C++, and other languages into LLVM bitcode that allows for client-side translation into the client's native instruction set. A white paper detailing the open source project is available here (pdf). ®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery

COMMENTS

House Rules Send Corrections

All Reader Comments (9)

Highly Rated

Posted Friday 19th March 2010 08:55 GMT

Tom 7

ARM netbooks - yeh right!

Who wants a small pocket-able PC that runs for 10hours on a charge and does everything you need in this modern computing world?

Intel and MS say no-one does so it wont happen.

Posted Friday 19th March 2010 08:55 GMT

sleepy

p-code? you youngsters know nothing

p-code came after the late 60's o-code, used in BCPL.

Elegant and expressive BCPL was sidelined by its illiterate bastard C derivative, which blighted my entire career even more than Microsoft the destroyer did. Forgive them Lord, for they knew not what they did.

Yes, this is also precisely Java and the JVM all over again, among others. In o-code days machine memory was about 10^5 bytes; today it's about 10^10. So with each order of magnitude increase, we've seen a new attempt at the same problem. Microsoft's is proprietary, natch. Maybe this LLVM iteration will finally stick, with Google's backing.

And for those not paying attention at the back of the class, this is the only way you're going to be able to distribute compiled code on the next generation of platforms without going via the platform owner's provenance-auditing app store. And a good thing too. Live with it, and get off Apple's case.

Posted Friday 19th March 2010 12:28 GMT

sleepy

What makes you think that?

If browser plugins are adequately sandboxed and restricted to API's that don't threaten privacy or security, and battery life has been improved sufficiently, I see no reason why not. Of course the plugin itself would be delivered by Apple, not Google. (Like Chrome, Safari on Mac already runs plugins in a separate process.)