私が理解していることから、プロセッサ回路はチップごとに大きく異なるため、同じ高レベルコードを実行するために異なる低レベル命令が必要になる場合があります。すべてのプログラムは最終的に生のマシン コードになる前にアセンブリ言語に変換されますか、それともこの手順は不要ですか?
もしそうなら、プロセッサはどの時点で独自の命令セットを実行し始めますか? これはコードの最下位レベルであり、プログラム命令がプロセッサによってビットごとに実行されるのはこの時点でしょうか?
最後に、すべてのアーキテクチャにアセンブリ言語がある/必要ですか?
アセンブリ言語は、いわば、プロセッサが実行する命令 (バイナリ データであり、人間が管理するのは非常に難しい) を表現する人間が読める形式です。そのため、機械命令が人間によって生成されない場合、アセンブリ ステップを使用する必要はありませんが、便利な場合もあります。プログラムが C++ などの言語からコンパイルされている場合、コンパイラは、アセンブリ コードの中間段階を経由せずに、マシン コードを直接生成することがあります。それでも、多くのコンパイラは、人間が生成されたものを簡単に検査できるようにするために、アセンブリ コードを生成するオプションを提供しています。
Java や C# などの多くの最新言語は、いわゆるバイトコードにコンパイルされます。これは、CPU が直接実行するコードではなく、中間形式であり、プログラムの実行時にジャストインタイム (JIT-ted) にマシン コードにコンパイルされる可能性があります。このような場合、CPU に依存するマシン コードが生成されますが、通常は人間が読み取れるアセンブリ コードを経由しません。
アセンブリ言語は、生のマシン コードを人間が判読できるテキスト表現にすぎません。(人間の) プログラマーの利益のために存在します。マシンコードを生成するための中間ステップとしてはまったく必要ありません。一部のコンパイラはアセンブリを生成し、アセンブラを呼び出してそれをマシン コードに変換します。しかし、そのステップを省略するとコンパイルが高速化されるため (そしてそれほど難しくはない)、コンパイラは (大まかに言えば) マシンコードを直接生成する方向に進化する傾向があります。ただし、結果を検査するために、アセンブリにコンパイルするオプションがあると便利です。
最後の質問ですが、アセンブリ言語は人間にとって便利なものであるため、アーキテクチャで本当に必要とされるものはありません。本当に望むなら、アーキテクチャなしでアーキテクチャを作成できます。しかし実際には、すべてのアーキテクチャにアセンブリ言語があります。まず、新しいアセンブリ言語を作成するのは非常に簡単です。マシンのすべてのオペコードとレジスタにテキスト名を付け、さまざまなアドレス指定モードを表す構文を追加すれば、ほとんど完了です。また、すべてのコードが高水準言語から機械語に直接変換されたとしても、コンパイラのバグを探すときなどに機械語を逆アセンブルして視覚化する方法としてのみ、アセンブリ言語が必要です。
すべての汎用 CPU には独自の命令セットがあります。つまり、特定のバイト シーケンスが実行されると、よく知られており、文書化されているように、レジスタとメモリに影響を及ぼします。アセンブリ言語は、これらの命令を書き留める便利な方法です。これにより、人間は命令を読み書きし、常にコマンドを検索しなくても命令の動作を理解できます。最新のすべてのCPU にアセンブリ言語が存在すると言っても過言ではありません。
さて、プログラムをアセンブリに変換するかどうかについて。CPU はアセンブリ コードを実行しないということから始めましょう。マシン コードを実行しますが、マシン コードのコマンドとアセンブリ ラインの間には 1 対 1 の対応があります。その区別を念頭に置いている限り、「CPU が MOV を実行し、次に ADD を実行する」などと言うことができます。もちろん、CPUはMOVコマンドに対応するマシンコードを実行します。
つまり、言語がネイティブ コードにコンパイルされる場合、実際には、プログラムは実行前にマシン コードに変換されます。一部のコンパイラ (すべてではありません) は、アセンブリ ソースを発行し、アセンブラに最終ステップを実行させることでこれを行います。このステップが存在する場合、通常は十分に隠されています。アセンブリ表現は、コンパイラにそのまま保持するように指示しない限り、コンパイル プロセス中に短時間だけ存在します。
他のコンパイラはアセンブリ ステップを使用しませんが、必要に応じてアセンブリを発行します。たとえば、Microsoft C++ はオプション /FA を使用して、アセンブリ リストをオブジェクト ファイルと共に出力します。
インタープリター言語の場合、機械への明示的な変換はありません。ソース行は、言語インタープリターによって実行されます。バイトコード指向の言語 (Java、Visual Basic) はその中間に位置します。それらは機械語と同じではないコードにコンパイルされますが、高レベルのソースよりも解釈がはるかに簡単です。それらについては、機械語に変換されていないと言っても過言ではありません。
すべてのプロセッサはビットで動作します。私たちはそれをマシンコードと呼びます。さまざまな理由で非常にさまざまなフレーバーを帯びることがあり、アイデアを保護する特許に対するより良いマウストラップを構築します. すべてのプロセッサは、ユーザーの観点からマシンコードのフレーバーを使用し、内部でそれをマイクロコードに変換するものもあれば、別のマシンコードに変換するものもあれば、そうでないものもあります。x86 対 arm 対 mips 対 power pc と聞くと、それは単なる会社名ではなく、それぞれのプロセッサ用に独自の命令セット (マシン コード) を持っています。x86 命令セットは進化していますが、依然としてその歴史に似ており、x86 コードを他のコードから簡単に選ぶことができます。そして、それはすべての企業に当てはまります。mips の遺産が mips に見られ、腕を組んでいることなどを見ることができます。
したがって、ある時点でプログラムをプロセッサで実行するには、そのプロセッサのマシンコードに変換する必要があります。その後、プロセッサはそれを処理できます。さまざまな言語とツールがさまざまな方法でそれを行います。コンパイラが高級言語からアセンブリ言語にコンパイルする必要はありませんが、便利です。まず、基本的にそのプロセッサ用のアセンブラが必要になるため、ツールはそこにあります。2 つ目は、機械語のビットとバイトではなく、人間が読めるアセンブリ言語を調べることで、コンパイラのデバッグがはるかに簡単になる可能性があります。JAVA、python、古いパスカル コンパイラなどの一部のコンパイラには、x86 上の Java とアーム上の Java がその時点まで同じことを行うという意味でユニバーサルなマシン コード (各言語には独自の異なるコードがあります) があります。ターゲット固有です（x86、arm、mips) インタープリタは、ユニバーサル バイトコードをデコードし、ネイティブ プロセッサで実行します。しかし、最終的には、それが実行されているプロセッサのマシン コードでなければなりません。
これらのコンパイルレイヤーのこの方法にはいくつかの歴史もあります.1つのブロックをフロントエンドにし、別のブロックをバックエンドにしてasmを出力し、オブジェクトへのasmはそれ自体です.他のツールとリンクされたオブジェクトは、独自のツールです。各ブロックは、制御された入力と出力で含まれ、開発され、同じ場所に収まる別のブロックに置き換えられる場合があります。コンパイラ クラスはこのモデルを教えるので、新しいコンパイラと新しい言語でそれが複製されることがわかります。フロントエンド、高級言語のテキストを解析します。中間のコンパイラ固有のバイナリ コードに変換し、バックエンドでその内部コードを取得して、ターゲット プロセッサ用のアセンブリに変換します。たとえば、gcc や他の多くのバックエンドを変更して、フロントとミドルを異なるターゲットに再利用できるようにします。次に、アセンブラと別のリンカ、別のツールを個別に用意します。
人々はキーボードとマウスを再発明しようとし続けていますが、新しい発明がはるかに優れていたとしても、人々は古い方法に固執するのに十分満足しています. 同じことがコンパイラーやオペレーティング・システムにも当てはまり、他の多くのことについても、私たちが知っていることと、アセンブリー言語にコンパイルされることが多いコンパイラーを使用します。
これは、あなたが見下ろしているかなり大きなウサギの穴です。
そうは言っても、すべてのプログラムがアセンブリ言語に変換されるわけではありません。ジャスト イン タイム コンパイルを除外すると、Ruby、Lisp、Python などのインタープリター言語、および Java や C# などの仮想マシン (VM) 上で実行されるプログラムはアセンブリに変換されません。むしろ、既存のプログラム、つまりソース (解釈された) またはバイトコード (VM) (コンピューターのアセンブリ言語ではない) を取り込んで実行するインタープリターまたは仮想マシンがあります。インタプリタは、特定の入力シーケンスを認識したときに何をすべきかを知っており、その特定の入力を以前に見たことがなくても、正しいアクションを実行します。
C や C++ で記述したようなコンパイル済みプログラムは、コンパイル プロセスの一部としてアセンブリ言語に変換され、その後機械語に変換されます。多くの場合、このステップは処理を高速化するためにスキップされます。LLVM などの一部のコンパイラは汎用ビットコードを出力するため、ビットコードをマシン コードに変換する部分からビットコードを生成するコンパイラの部分を分割し、アーキテクチャ間で再利用できます。
ただし、OS は CPU をマシン コードを消費するものと見なしますが、多くの CPU には低レベルのマイクロコードがあります。命令セット内の各命令 (アセンブリレベル) は、一連の単純なマイクロコード操作として CPU によって実装されます。命令を実装するマイクロコードが変更されても、CPU 間で命令セットを同じままにすることができます。命令セットは、CPU の API と考えてください。
基本的にはい、Java のアセンブリはバイトコードと呼ばれ、チップのマイクロアーキテクチャには、アセンブリ命令などで構成されるISAがありますが、同じ ISA を多くの異なるチップで実現できます。MIPS を学べば、コンパイラによって C がどのように MIPS に変換されるかを学ぶことができるようになるための良い入門書になります。次に、MIPS 命令がマシン コードにどのように変換されるかを確認できます。そのマシン コードには、命令を実行するALUへのオペコードがあります。詳細については、コンピューター ハードウェアに関する 2 つの優れた本を執筆している Hennessy / Patterson を参照してください。
ネイティブ マシン コードを生成するコンパイラは、マシン コードにアセンブルされる適切なアセンブリ言語を生成します。これは通常、1 つのステップで実行されますが、GCC などの一部のコンパイラは、中間アセンブリも出力できます。
異なるアーキテクチャには異なる命令セットがあるという点で正しいです。これらの違いを利用することは、コンパイラが実行可能ファイルをプロセッサごとに最適化する方法です。
Here's some of what may be confusing you: