バイト‐コード【byte code】
バイトコード
バイトコード
(Bytecode から転送)
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/03/21 21:24 UTC 版)
|
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 (2025年2月)
|
| プログラムの実行 |
|---|
| 一般的な概念 |
| コードの種類 |
| コンパイル戦略 |
| 有名なランタイム |
|
| 有名なコンパイラとツールチェーン |
|
バイトコード（英: bytecode / byte code）とは、プログラムを仮想マシンが実行できる形に変換した中間命令列である[1]。ソースコードと機械語の中間に位置づけられ、異なる計算機環境間でのプログラムの移植性確保や実行処理の効率化を目的として用いられる。一般に命令はバイト単位で構成され、解釈実行や後段の最適化処理を行いやすい構造を持つ。
存在意義
ソースコードを直接解釈するインタプリタと同等の移植性を確保した上でのインタプリタのパフォーマンスの高さや、ソースコードの隠蔽が目的であれば、なんらかの中間表現で足りる。 それら中間表現の中でのバイトコードあるいはワードコードの意義は、得られるインタプリタの解釈実行パフォーマンスが最も高いことである。
多くのコンピュータにはバイト単位のメモリアクセスに特化した命令が用意されている。 あるいは、コンピュータのメモリアクセスは、そのコンピュータ固有の大きさのワード単位でのものが最も効率的である。 さらに、実ハードウェアの機械語のパフォーマンスを上げるため、機械語と同様に後続アドレスを順次読み込むメモリアクセスパターンは、多くのコンピュータのメモリシステムで最適化されている。 この、コンピュータにとって最も効率的なメモリ単位とアクセスパターンに、表現体系を合わせたものがバイトコードあるいはワードコードである。 このパフォーマンス上の利点から、現在の多くのインタプリタ言語は実際にはバイトコードにコンパイルされた後、バイトコードインタプリタによって実行される。
純粋なJavaのプログラムはプラットフォーム独立であり、実行環境（Java Runtime Environment, JRE）さえインストールされていればどこでも実行可能であるだけでなく、実行時コンパイラを使ってプロセッサ固有の機械語に随時変換することによってパフォーマンスを確保できることから、エンドユーザー向けにはバイトコードにコンパイルしてJARファイルとしてアーカイブしたものが配布されていることが多い。ソースコードを秘匿するプロプライエタリソフトウェアにも都合がよい。
また、中間表現の中でも実ハードウェアの機械語に最も類似したものなので、機械語に変換する直前の中間表現としても使われることがある。 バイトコードを使用した初期のコンピュータにはSystem/38があり、ソフトウェアのインストール時に機械語に変換された。
スタックマシン vs レジスタマシン - その論点
バイト指向でない中間コードもバイトコードも、その多くは、実ハードウェアの機械語と似た命令フォーマットや命令セットの構成をとっている[注釈 1]。ただし、ハードウェアで実装されたプロセッサでは比較的、スタックマシンよりレジスタマシンの方が多いのに対し、ソフトウェアによる仮想機械や抽象機械ではJava仮想マシンなどスタックマシンも多いという特徴がある。なお、Luaのバージョン5やDalvik仮想マシンなど、レジスタマシンも多い。
理論的観点
「抽象機械」と呼ばれるような計算モデルとしての性格が強い機械の場合、理論的な扱いのためにスタックが使われているものもある。
命令の粒度
レジスタマシン型命令セットではオペランドの位置を命令内で明示する。これに対しスタックマシン型命令セットでは、暗黙のうちにスタックトップをオペランドとして使い、オペランドの位置を明示する領域が不要である。目的のオペランドがスタックトップにない場合にはオペランド移動のための命令を追加する。大まかに言えば、スタックマシン命令1個当たりの長さと機能は、レジスタマシン1命令内の個々のオペランドフィールド1個、またはコードフィールドと同等である。
このためバイトコード全体の長さには大差はなさそうだが、スタックマシンでは命令順を並び換えることでオペランド移動命令を略せる場合がある。レジスタマシンではオペランド指定は省略できないので、オペランド移動を省略した分だけスタックマシンの方が同等のプログラムを短く記述できる場合が多い。またデータキャッシュヒット率が高まるので、プログラムサイズ削減は実効速度改善にもなる。
しかしオペランド移動の省略を施しても、スタックマシンの方がレジスタマシンより命令数が多くなる。個々の命令が極めて単純な処理しか行わないバイトコードインタプリタでは、命令の種類を判定して分岐する処理が実行時間の大きな割合を占めるので、この点ではレジスタマシンの方が有利となる。
命令間でのオペランドの受け渡し
レジスタマシン型インタプリタでは番号で仮想レジスタを指定するが、多くの実機では実行時に物理レジスタを番号で参照することができないため、メモリ配列によって仮想レジスタが実装されている場合が多い。これに対しスタックマシン型インタプリタでは、ほとんどの命令のオペランドがスタックトップに決め打ちされ、参照すべき物理レジスタをコンパイル時に決定できるので、スタックトップ数個を物理レジスタで実装している。多くの実機ではレジスタ経由でのデータ受け渡しは1クロックでできるのに対し、メモリ経由でのデータ受け渡しは数クロックを要するので、直前の命令の結果を直後の命令が使う処理が連なった場合は、レジスタマシンは不利となる。
ソースコードからバイトコードへの変換
ALGOL以来、多くのプログラミング言語は文脈自由文法で記述でき、スタックマシンと類似したプッシュダウン・オートマトンで構文解析できる。このため、スタックマシン向けのコード生成器ならば、構文解析器と一体化させて省メモリ・高速なものにできる。
レジスタマシン向けの場合、有限のレジスタを使い回すレジスタ割り付けを行う必要がある。ただし、インタプリタの仮想レジスタはメモリ配列で実装されている場合が多い。このため、メモリ配列の大きさが許す限り、実機では非現実的な膨大な数の仮想レジスタを実装でき、その場合、レジスタの使い回しを省いてレジスタ割り付けを単純化することができる。レジスタ・ウィンドウも僅かなコストでレジスタ1本単位でスライドさせる柔軟なものが実装でき、スタックマシン向けと同様に構文解析器とコード生成器の一体化に役立つ。[1]
使用例
- System/38 - TIMI (Technology Independent Machine Interface)
- Java - Javaバイトコード
- .NET Framework/.NET - 共通中間言語 (CIL)
- Raku
- Ruby 1.9
- JavaScriptの処理系の一部
- Microsoft DirectX（Direct3D）のシェーダーバイトコード（DXBC/DXIL）
脚注
注釈
- ^ 実機ではデコーダやエンコーダといった論理回路に向いたビットパターンのほうが好まれるといった細かい傾向の違いなどはある。
出典
関連項目
 |
この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
- Bytecodeのページへのリンク
