[訂正記事]グーグルのNative Client、CPUに依存しない互換性は将来のバージョンにて

2010年3月21日

3月19日付けの記事「グーグル、Native Clientをx86-64とARMにも。同一バイナリが主要なCPUで動作」について、誤解した表現がタイトルと本文に含まれていたため、お詫びして訂正させていただきます。すいませんでした。

訂正内容

この記事では、タイトルと本文を含め、x86用のNative Client対応バイナリが新たにグーグルが開発したX86-64とARM用のNative Clientでもそのまま動作するとの説明をしましたが、その部分は誤りでした。

正しくは、グーグルはこれまでのx86用Native Clientに加えて、x86-64用、ARM用のNative Clientを開発しましたが、現時点ではそれぞれのCPUに合わせてソースコードをコンパイルし、バイナリを生成する必要がありました。

グーグルはNative Clientの今後の計画として、CPUの命令セットに依存しないPortable Native Client(PNaCL)を開発中です。このPNaCLではLLVM(Low Level Virtual Machine)のbitcodeという、CPUの命令セットに依存しないバイナリ形式を用い、そこからさらに各CPUのバイナリコードへとダイナミックに変換します。これにより将来はCPUに依存しない(P)NaCLのバイナリコードが実現することになります。

詳細

グーグルは、今回の発表に合わせて2本の文書をPDFで公開しています。

前者は、今回グーグルが発表したx86-64とARM対応のNaCLについて技術的にどのような課題があり、それをどう解決して実装したかについて説明した文書です。

This paper describes and evaluates analogous designs for two more recent instruction set implementations, ARM and 64-bit x86, with pure software-fault isolation (SFI) assuming the role of segmented memory.

後者は、現在開発中のPNaCLの技術的な説明のための文書です。そこには次のような説明があります。

NaCl modules can thus harness the full power of the client machines' CPUs and other resources, but to do so, a compiled NaCl module must necessarily be tied to a specific instruction set architecture (ISA). This poses a threat to the portability of the web,

つまり現状のNaCLは、それぞれのCPUの命令セットに依存したバイナリをデベロッパーが用意する必要があり、それはWebのポータビリティに対する脅威になるとしています。

それを解決するためにPNaCLが開発されています。PNaCLの目標は次のように説明されています。

  1. Provide an ISA-neutral format for compiled NaCl modules supporting a wide variety of target platforms without recompilation from source.
  2. Make it easy for NaCl developers to build, test and deploy portable executable modules.
  3. Support the x86-32, x86-64 and ARM instruction sets initially, but make it straightforward to support other popular general-purpose CPUs in future.
  4. Preserve the security and performance properties of Native Client.

再コンパイルせずに幅広いプラットフォームをサポートする、命令セットからニュートラルなコンパイル済みのNaCLモジュールを提供し、それをデベロッパーが容易に開発でき、将来のCPUにも対応した、高速で動作するセキュアなフォーマット、というのがその概要です。

そのために用いられるのがLLVM bitcodeです。デベロッパーはソースコードをこのbitcod形式にコンパイルします(下記の図の左側)、それがPortable Executableなバイナリとなり、Webサーバにデプロイします(下記の図の中央)。クライアントはそれをロードしたときにCPUに合ったバイナリへと変換し、NaCLが実行する、というのが全体の構造となります(下記の図は「PNaCL: Portable Native Client Executables」から引用)。

fig

間違いをご指摘いただいたみなさま、ありがとうございました。今後もより正確な情報をお届けできるように努力していきます。

Tags: Web技術 Web標準 Google

このエントリーをはてなブックマークに追加
ツイート
follow us in feedly




タグクラウド

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準

アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本