VMが「スタックマシン」または「レジスタマシン」などである必要があるのはなぜですか？

_{（これは非常に初心者向けの質問です）。}

私は仮想マシンについて少し勉強しています。

それらの多くは、物理的または理論的なコンピューターと非常によく似た設計になっています。

たとえば、JVMは「スタックマシン」であると読みました。それが意味することは（そして、私が間違っている場合は私を修正します）、すべての「一時メモリ」をスタックに保存し、そのすべてのオペコードに対してこのスタックで操作を行うことです。

たとえば、ソースコード2 + 3は次のようなバイトコードに変換されます。

push 2
push 3
add

私の質問はこれです：

JVMはおそらくC / C ++などを使用して記述されています。もしそうなら、なぜJVMは次のCコードを実行しません：2 + 3..？つまり、なぜスタックが必要なのか、または物理コンピューターのように他のVMの「レジスタ」に必要なのでしょうか？

基礎となる物理CPUがこれらすべてを処理します。VMライターが、VMがプログラミングされている言語の「通常の」命令で、解釈されたバイトコードを単に実行しないのはなぜですか？

実際のハードウェアが既にこれを行っているのに、なぜVMがハードウェアをエミュレートする必要があるのですか？

繰り返しますが、初心者向けの質問です。ご協力いただきありがとうございます

仮想マシンであろうとなかろうと、マシンには計算の実行方法を記述する計算モデルが必要です。定義により、計算するとすぐに、何らかの計算モデルを実装します。質問は次のとおりです。VMにはどのモデルを選択する必要がありますか？物理マシンは、ハードウェアで効果的かつ効率的に実行できるものに制約されます。ただし、ご指摘のとおり、仮想マシンにはこのような制約はなく、任意の高レベル言語を使用してソフトウェアで定義されます。

実際、あなたが説明しているように高レベルの仮想マシンがあります。それらはプログラミング言語と呼ばれます。たとえば、C標準は、そのページの大部分を、Cプログラムの動作方法、および拡張（as-ifルール）による準拠Cコンパイラ（またはインタープリター）を記述するいわゆる「C抽象マシン」のモデルの定義に専念します。振る舞うべきです。

もちろん、通常は仮想マシンとは呼びません。通常、VMとは、直接プログラムすることを意図したものではなく、効率的に実行されるように設計された、ハードウェアに近い低レベルのものを意味します。この選択バイアスは、高レベルのコードを実行するため、高レベルのコンポーザブルコード（説明したような）を受け入れるものはVM とは見なされないことを意味します。

しかし、わかりやすくするために、VMを（バイトコードコンパイラがターゲットとするもののように）レジスタベースなどにする理由をいくつか示します。スタックおよび登録マシンは非常に簡単です。命令のシーケンス、状態、および各命令のセマンティクスがあります（関数State-> State）。複雑なツリーの縮小も、演算子の優先順位もありません。構文解析、分析、実行は非常に簡単です。なぜなら、それは最小限の言語であり（構文糖はコンパイルされて）、人間が読むのではなく機械で読むように設計されているからです。

対照的に、最も単純なCライクな言語でさえ解析するのは非常に難しく、その実行には型のチェックと伝播、オーバーロードの解決、シンボルテーブルの維持、文字列識別子の解決、線形テキストの優先順位駆動型ASTへの変換などの非ローカル分析が必要です、 等々。それは人間にとって自然な概念に基づいて構築されていますが、機械によって骨の折れるリバースエンジニアリングが必要です。

たとえば、JVMバイトコードはによって発行されjavacます。人間が読み書きする必要はほとんどないので、機械による消費に合わせて調整するのが自然です。それを人間向けに最適化すると、JVMはスタートアップのたびにコードを読み取り、解析し、分析し、とにかくそのような単純化されたマシンモデルに似た中間表現に変換します。中間者も切り抜くかもしれません。

この回答はJVMに焦点を当てていますが、実際にはすべてのVMに適用されます。

実際のハードウェアが既にこれを行っているのに、なぜVMがハードウェアをエミュレートする必要があるのですか？

そうではありませんが、VMが非常にシンプルでポータブルになります。ハードウェアをエミュレートするVMは、ハードウェアCPUと同じ計算モデルを使用できます。

特に、JVMは移植性を念頭に置いて構築されており、実際にはハードウェアで実装することさえできるように構築されています（今日は信じがたいかもしれませんが、Javaの起源は組み込みの世界、特にインタラクティブテレビのコントローラーにあります） ）。

このような目標がある場合は、実際のマシンコードへの変換がより簡単になり、より高速になるため、VMをできるだけ物理マシンの近くで動作させることが望ましいです。VMのオペコードを取得したら、理論的には、プログラムが実際に実行されるCPUのオペコードに変換するだけです。実際には、それほど単純ではありません。

つまり、なぜスタックが必要なのか、または物理コンピューターのように他のVMの「レジスタ」に必要なのでしょうか？

スタックベースの仮想マシンモデルを使用することには、レジスタマシンとスタックマシンの両方に簡単に転送できるという利点がありますが、逆は必ずしも当てはまりません。レジスタベースのVMでは、レジスタの数、レジスタのサイズなどについて仮定する必要があります。スタックマシンでは、そのような仮定は必要ありません。

基礎となる物理CPUがこれらすべてを処理します。VMライターが、VMがプログラミングされている言語の「通常の」命令で、解釈されたバイトコードを単に実行しないのはなぜですか？

まあ、それはそのようなVMが行うことです、彼らはバイトコードを解釈します。少なくともJIT（ジャストインタイム）が始まる前に、JVMでさえ実際にそれを行います：バイトコードを解釈し、JVMが記述された言語（通常はCまたはC ++ですが、1つでも記述されています）でステートメントを実行しますJavaScript、Doppioで）。ただし、このようなステートメントもコンパイラによってマシンコードに変換され、実際にはJavaコンパイラが生成するものと非常に似ていることに注意してください。つまり、レジスタとスタックを使用して作業を実行します。この時点では、「解釈済み」言語と「コンパイル済み」言語の使用が多少ぼやけていることに注意してください。

VMが「スタックマシン」または「レジスタマシン」などである必要があるのはなぜですか？

彼らはしない。仮想マシンが必要な場合は、何でもかまいません。

既存の仮想マシンは、次のような状況に対する解決策として登場しました。本当に素晴らしいアイデアが頭に浮かび、新しいプログラミング言語を発明しました！しかし、コードを生成する必要があります。（なんてつまらないタスクでしょう！）しかし、i8086コードはgenerateいので生成したくありません。また、他のみんながIntelを使用しているので68kコードを生成したくありません。VAXもありますが、私にはVAXはなく、コンピューターもVAXの本もありません。したがって、物理的に存在しない一部のプロセッサ用のコードを生成し、そのプロセッサをソフトウェアに実装します。そのVMの仕様は、私の論文の章になります。理論的には、任意のプロセッサのネイティブコードにコンパイルすることは可能ですが、それは私ではありません。

一方、「2 + 3」のような表記は、何かが実行される前に多くの変換を行うことを意味するため、おそらく近い将来VMによって使用されません。

尋ねられた実際の質問に答えるため。「仮想マシン」という用語は、すべてのソフトウェア/ハードウェアがシミュレート/エミュレートされることを意味します。基礎となるソフトウェア/ハードウェアを使用して命令を実行する場合、VMがなく、コンパイラ/インタープリターがあります。