機械語

機械語（きかいご、、 binary machine languageあるいはbinary machine code）は、コンピュータの中央処理装置（CPU)が直接理解し実行することができる命令からなる言語。マシン語（マシンご）とも。
概要.
機械語は0や1を並べた形、ビットの組み合わせパターン（ビット列）で表されるものであり、人間が日常使う言葉とはかけ離れていて読み書きしやすい形式ではない。
そのため、コンピュータのプログラムの開発に機械語が直接使われることはほとんどない。通常は人間が読みやすい形式（高級言語）でプログラムを書いてそれをコンパイラで機械語に翻訳してその機械語でコンピュータを動かしている。（ただし組込システムのエンジニアなどハードウェア寄りのエンジニアは機械語モニタを用いて機械語を直接操作することもある。）
機械語は中央処理装置（CPUやMPU）の動作をひとつひとつ指示するものであり、指示の内容はたとえば次のようなものである。
各プロセッサは、その設計段階で命令セットアーキテクチャ（ISA：Instruction Set Architecture）が定められ、そのISAの中で各命令の識別番号（オペコード）を定められる。機械語のプログラムは、基本的には、その識別番号（と操作対象のデータ）を実行順に並べた形式になっている。
機械語の体系は、CPU（MPU）のアーキテクチャごとに大きく異なっている。あるアーキテクチャのCPUのための機械語は、別のアーキテクチャのCPUには全く使えない。→#機械語と互換性
現在ではコンピュータのプログラムは基本的には高級言語で書くということはすでに説明したが、ハードウェア寄りのエンジニアなどがあえて機械語レベルのプログラムを作成する場合でも、大抵は機械語そのものを直接書くのではなく、機械語と1対1で対応するアセンブリ言語を使っている。→#機械語とアセンブリ言語、エンジニアが機械語を使用する状況
機械語の具体例.
次に機械語の命令群が書かれた具体例を示す。
CASLのペーパーマシンCOMETについて、情報処理技術者試験の出題範囲を示す資料に処理系作成者に対する便宜として、定義の後に付されている参考資料（定義ではない）にもとづく機械語の例を以下に挙げる。なお、この機械語コードは16進数表現（※）であり、2バイト単位で区切って（※）ある。
構成.
一般的な機械語プログラムは以下のような構成となっている。
以上の各部分に具体的に何ビットずつ割り振って、どういう順番に並べるか、という形式（フォーマット）のことを機械語フォーマットなどと言う。アーキテクチャにより機械語フォーマットはまちまちだが、1命令を構成するデータ長が固定の「固定長」式と、命令やオペランドの種類により変化する「可変長」式に大別される。可変長の場合、機械語命令の種類によってアドレス部やデータ部、そして中には命令部までも長さが変わる。このため、読み込み位置が1バイトずれれば機械語の命令はそれ以降のすべての命令が正しく読み込まれず意味を失うため、そういった機械語フォーマットのバイナリを対象とする逆アセンブラは工夫を要する。またメモリが限られるシステムでは本来の命令の途中に飛び込み別の意味に使うというトリック的な手法もある。
機械語と互換性.
基本的に、あるアーキテクチャの中央処理装置のための機械語は、別のアーキテクチャの中央処理装置のためには全く使えない。
たとえば、Pentium系列とPowerPC系列の双方で動く機械語プログラムが存在しないのは、命令セットに互換性が無いからである。
たとえ同じメーカー（や同系列企業）の中央処理装置でも、ある世代の中央処理装置のための機械語が、そのアーキテクチャの「世代」が代替わりし、アーキテクチャが変化すると、全く動かない。機械語プログラムがそのまま動くか否か、という互換性を「バイナリ互換性」と言う。
この常識を変えてみようと試みられたことがあり、1994年にIBMからコンセプトが公表されたプロセッサはx86とPowerPC命令の両立を目指し、32-bit PowerPC コード、64-bit PowerPC コード、32-bit x86 コードの実行が可能になる、という構想のものだったが、結局量産には至らなかった。
CPUによる仕様の差異.
CPUの仕様が異なれば、機械語もそれぞれのCPUごとに異なる。上記類似点の範囲でのCPUごとの機械語の仕様の差異には、以下のようなものが挙げられる。
パターン.
機械語で書かれたコードには頻出するパターンが存在する。
関数.
機械語に関数構文は存在しないが、関数に相当するパターンが存在する。
関数は引数を受け取り、ローカル変数を確保し、ボディの命令を実行し、戻り値を返すルーチンである。このルーチンを呼び出す場合、制御が戻るポイントを控え、引数を用意し、ルーチンへ制御を移して実行し、戻り値を記録し、戻りポイントへ制御を移す。
これらの処理によりサブルーチンへ制御が移り、関数ボディの命令列が実行される。関数命令の最終行が実行されたのち、次の処理が必要となる。
これらの処理によりメインルーチンへ制御が復帰する。
このパターンは関数の処理内容に関わらず普遍的である。前半の関数呼び出しに相当するパターンを関数プロローグ（）という。後半の関数からの復帰に相当するパターンを関数エピローグ（）という。
関数プロローグ・エピローグは同じ結果が得られるいくつかのパターンが存在する（呼出規約）。例えば引数をスタックに積むパターンとレジスタに置くパターンがある。
機械語とアセンブリ言語.
機械語を扱いたい場合でも機械語は0/1の組合せや16進表記であり扱いづらいので、代わりにアセンブリ言語を使うことが一般的である。アセンブリ言語は、プログラミング言語の中では機械語に一番近く、機械語とほぼ1対1に対応し、なおかつ人間に理解しやすいニーモニックで書ける。
アセンブリ言語で書かれたプログラムを機械語に変換すれば、その機械語でコンピュータは動く。（アセンブリ言語で書かれたプログラムを機械語に変換することをアセンブル（する）と言う。）アセンブラというソフトウェアを使えばアセンブリ言語から機械語への変換を自動的に行うことができる。
一方、逆アセンブラというものもあり、これはアセンブラと逆向きの作業、つまり機械語のプログラム（機械語コード）をアセンブリ言語に変換するソフトウェアである。アセンブラと逆アセンブラを使うことで、機械語←→アセンブリ言語 の間の変換を自在に行うことができる。
なお基本的にはアセンブリ言語は機械語と1対1に対応するが、若干の例外はあり、簡単なマクロなどを備えているものは多く、遅延スロットを利用するコードに自動的に変形するなどといった機能を持つものもある。また特殊な短縮形など（x86でAXがオペランドの場合など）について、機械語では違いがある場合をアセンブリ言語では明示的に指定できない場合もある。
システム開発の際の文書（仕様書）が失われることはよくある事だが、文書が残っていないシステムを分析する場合、プログラムを解析するしか方法が無いことがあり、特にソースコードも残っていないような場合には、機械語コードを解析するしかなくなる。そのような場合は、逆アセンブラで逆アセンブルつまり機械語からアセンブリ言語に変換することで、最低限ではあるが、機械語コードを解析できるようになる。さらにヒューリスティックな機能を備えたソフトウェアも使えれば、ソースコードのサブルーチン名や変数名などもある程度推測してくれる。ただしプログラムの"意味"を解析するのは人が行なう必要がある。
機械語プログラムの読み込み.
ここでは、プログラム内蔵方式を前提とする。一般に電源投入ないし、いわゆるコールドリセットの直後にCPUが実行するコードはROMに置いておくか、CPUの動作に依らない方法でRAMに書き込まれている必要がある（ブート）。
オペレーティングシステム（OS）がブートされた後の、OS運用下では、ファイルシステムが存在するシステムの場合、補助記憶装置中のファイルシステムに、いわゆる「実行可能バイナリ」などと呼ばれる実行ファイルとして機械語プログラムが存在しており、それがファイルシステムから主記憶にロードされて実行される、というような形態が一般的である。なお、実行時に共有ライブラリを動的リンクするなど、近年はこの「ロードして実行する」という手続きが複雑になる傾向もあり、実行時コンパイル等が一般的になると主流の形態も変化するかもしれない。
ダンプリスト.
ダンプリストそのものは機械語に限らず、コアダンプなど、バイナリをリスティング出力したものであり、オクテット単位を基本とするコンピュータでは十六進法の2桁ずつで表現される。また1980年頃の「マイコン雑誌」の誌面に機械語プログラムが掲載される際の形態でもあった。
命令セットと命令フォーマットの設計によって、ダンプリストではほとんど意味不明なコードの場合もあれば、比較的読みやすいものもある。前述のようなハンドアセンブルやハンド逆アセンブルの経験者であれば、かなりその場で読めるような者もいる。そうでなくとも、デバッグ等で頻出するパターン（システムコールやサブルーチン呼出、プッシュ・ポップ等）は、経験で覚えてしまうことも多い。
機械語が動いている状況とエンジニアが機械語を使用する状況.
現在でも全てのプログラムは、たとえ高級言語で書かれていようが、ユーザには見えていなかろうが、結局は全て機械語に変換されて実行されている。コンピュータの中央処理装置は常に機械語で動いている。コンピュータはどの瞬間も、機械語無しでは全く動かない。
コンピュータサイエンティストやエンジニアたちの数十年以上の努力の積み重ねのおかげでアセンブラが作られ、コンパイラも作られ、高級言語も作られ、便利なアプリケーション・ソフトウェアもあるので、現在では、一般ユーザも、パソコンしか触ったことがないような巷の若いソフトウェアエンジニアも、機械語は直接書いたり読んだりしなくても、コンピュータをそれなりに操れる。
だが、一般ユーザや巷のソフトウェアエンジニアが機械語を直接書いたり読んだりしていなくても、それは「彼らは直接書いたり読んだりしていない」というだけのことでしかなく、実際にはコンピュータの核心部分の中央処理装置は常に機械語で動いている。また、現在でもいわゆる「組み込み系のエンジニア」や「ハードウェア系のエンジニア」などは、しばしばアセンブラや逆アセンブラを扱う必要があり、アセンブラや逆アセンブラを使えばその画面には機械語そのものが表示されているのでそれを目にすることになる。こうしたエンジニアは、時には機械語を直接自分の目で読んだり書いたりする場合もある。また忘れてならないが、CPUやMPUの開発企業（たとえばインテルやAMDなど）で新たなCPUやMPUのアーキテクチャを設計するエンジニアたちは、しばしば機械語についてかなり深いレベルで検討しており、新たなアーキテクチャを創造する場合は新たな機械語も作り出す。
人間がわざわざ直接機械語を書いたり読んだりする場合は、以前は次のような理由であった。
今日では、GNU Binutilsないし同様なライブラリがあることも多く、そういったユーティリティやライブラリを使うことで、アセンブラ・逆アセンブラを書いたりリバースエンジニアリングなどですら、機械語に直接触れずできることも多い。そのため、巷のエンジニアたちが機械語を直接読んだり書いたりするのは、そのようなユーティリティやライブラリが（まだ）無い新しいプロセッサの場合や対応していない新機能などを使う場合、プログラミング言語には馴染まない特殊な命令を扱う場合、trampolineのようなテクニックが必要な場合、プロセッサのバグに当たった（等の可能性が疑われる）場合、何らかの理由でコアダンプを直接解析しなければならない場合、などに限られてきている。