すべてのコンピューターに対応したユニバーサルアセンブリ言語は可能ですか？

アセンブリ言語についていくつか質問をしたいと思います。私の理解では、機械語に非常に近いため、より高速で効率的になります。

さまざまなコンピューターアーキテクチャが存在するため、異なるアーキテクチャ向けにアセンブリで異なるコードを記述する必要がありますか？もしそうなら、なぜAssemblyではない、一度書く-どこでも言語の種類を実行する？単純に汎用化するのは簡単ではないので、一度書くだけで、さまざまな構成のほぼすべてのマシンで実行できますか？（それは不可能だと思いますが、具体的で詳細な答えが欲しいです）

Cが私が探している言語だと言う人もいるかもしれません。私は以前にCを使用したことはありませんが、おそらくJavaよりも高速かもしれませんが、Cはまだ高レベル言語だと思います。私はここで間違っているかもしれません。

アセンブリ言語は、コンピューターの命令セット用の命令を記述する方法で、人間のプログラマーが少し理解しやすい方法です。

アーキテクチャごとに異なる命令セットがあります。許可される命令のセットは、アーキテクチャごとに異なります。したがって、一度だけ実行するあらゆる場所にアセンブリプログラムを作成することは望みません。たとえば、x86プロセッサでサポートされる命令セットは、ARMプロセッサでサポートされる命令セットとは大きく異なります。x86プロセッサ用のアセンブリプログラムを作成した場合、ARMプロセッサではサポートされていない命令が多数あり、その逆も同様です。

アセンブリ言語を使用する主な理由は、プログラムを非常に低レベルで制御でき、プロセッサのすべての命令を利用できることです。特定のプロセッサに固有の機能を利用するようにプログラムをカスタマイズすることによりで実行され、時にはプログラムを高速化できます。一度だけ実行するあらゆる場所での哲学は、基本的にそれと対立しています。

アセンブリ言語の定義は、アセンブリコードをマシンコードに直接翻訳できる言語であるということです。アセンブリ言語の各操作コードは、ターゲットコンピューターで1つの操作に変換されます。（まあ、それよりも少し複雑です。一部のアセンブラは、オペコードへの引数に基づいて「アドレス指定モード」を自動的に決定します。しかし、原則として、アセンブリの1行が1つの機械語命令に変換されます。）

アセンブリ言語のように見えるが、異なるコンピューター上の異なるマシンコードに翻訳される言語を発明することができます。しかし、定義により、それはアセンブリ言語ではありません。これは、アセンブリ言語に似た高レベル言語になります。

あなたの質問は、「フロートせず、水上を移動する他の方法があるが、ホイールとモーターがあり、陸上で移動できるボートを作ることは可能ですか？」という質問に少し似ています。答えは、定義上、そのような乗り物はボートではないということです。車のように聞こえます。

世界中のすべてのコンピューターに1つのアセンブリ言語を使用することに対して、概念的な（あえてコンピューターサイエンスがない）理由はありません。実際、これにより多くのことがはるかに簡単になります。理論に関する限り、ファンキーな全単射まではとにかくすべて同じです。

ただし、実際には、目的ごとに異なるチップがあり、異なる目標に対応するさまざまな操作と設計原則（RISCとCISCなど）があり、それらを操作する命令セットとアセンブリ言語は異なります。最終的に、答えは、なぜ多くの異なるプログラミング言語があるのかを尋ねるときと同じです：異なる目標、異なる設計決定。

そうは言っても、当然のことながら、いくつかの共有インターフェースに到達するために抽象化のレベルを導入できます。たとえば、x86はかなり長い間、チップレベルで廃止されました。x86命令をプロセッサが実際に動作するものに変換する小さなハードウェアがあります。Cのような言語は、ハードウェア（おそらく非常に小さい言語）からさらに一歩進んで、Haskell、Java、Rubyなどの言語に至るまでです。はい、コンパイラーはコンピューターサイエンスの主な成果の1つです。コンパイラーは、この方法で懸念を分離できるようにするためです。

「一度だけ実行すれば書き込み」というフレーズは、その重要性に気付かずに言及します。それはのためのマーケティングのスローガンであるSun Microsystemsの商業の概念を発明した「仮想マシン」と「バイトコード」おそらくアイデアは学界1に由来しているかもしれないが、Java用の^ST。このアイデアは、Javaライセンスの侵害によりSunによって首尾よく訴えられた後、Microsoftによって.Netのためにコピーされました。Javaバイトコードは、クロスマシンアセンブリまたはマシン言語のアイデアの実装です。Java以外のいくつかの言語で使用され、理論的には任意の言語をコンパイルするために使用できます。長年にわたる非常に高度な最適化の後、Javaはコンパイルされた言語のパフォーマンスに近づき、プラットフォームに依存しない高性能な仮想マシンテクノロジーの目標が一般的に達成可能であることを示しています。

あなたの要件に関連する初期段階/循環の別の新しいアイデアは、再計算プロジェクトと呼ばれ、他の目的に使用することができますが、科学研究のためのものです。アイデアは、仮想マシン技術を介して計算実験を複製可能にすることです。これは主に、任意のハードウェアで異なるマシンアーキテクチャをシミュレートするという考えです。

高レベルの理由

あなたがそれについて考えるとき、マイクロプロセッサは驚くべきことをします：それはあなたが機械（洗濯機やエレベーターなど）を取り、安価で大量生産されたシリコンでカスタム設計されたメカニズムまたは回路のチャンク全体を置き換えることを可能にしますチップ。部品に多くのお金を節約し、設計に多くの時間を節約できます。

しかし、数え切れないほどのカスタムデザインに取って代わる標準チップです。すべてのアプリケーションに最適な単一の完璧なマイクロプロセッサは存在できません。一部のアプリケーションでは、電力使用量を最小限に抑える必要がありますが、高速である必要はありません。他のものは高速である必要がありますが、プログラムが簡単である必要はなく、他のものは低コストである必要があります。

したがって、マイクロプロセッサにはさまざまな「フレーバー」があり、それぞれに長所と短所があります。全員が互換性のある命令セットを使用することが望ましいです。これにより、コードの再利用が可能になり、適切なスキルを持つ人材を見つけやすくなります。ただし、命令セットは、プロセッサのコスト、複雑さ、速度、使いやすさ、および物理的制約に影響するため、妥協点があります。「主流」の命令セット（およびマイナーな命令セット）がいくつかあり、各命令セット内には、異なる特性を持つ多くのプロセッサがあります。

ああ、技術が変化すると、これらのトレードオフがすべて変化するため、命令セットが進化し、新しいセットが出現し、古いセットが消滅します。たとえ今日の「最高の」命令セットがあったとしても、それは20年ではないかもしれません。

ハードウェアの詳細

おそらく、命令セットでの最大の設計決定はワードサイズ、つまりプロセッサが「自然に」操作できる数値の大きさです。8ビットプロセッサは0〜255の数値を処理し、32ビットプロセッサは0〜4,294,967,295の数値を処理します。ある人のために設計されたコードは、別の人のために完全に再考される必要があります。

ある命令セットから別の命令セットに命令を変換するだけの問題ではありません。異なる命令セットでは、完全に異なるアプローチが望ましい場合があります。たとえば、8ビットプロセッサではルックアップテーブルが理想的ですが、32ビットプロセッサでは算術演算が同じ目的に適しています。

命令セットには他にも大きな違いがあります。ほとんどの指示は4つのカテゴリに分類されます。

• 計算（算術と論理）
• 制御フロー
• データ転送
• プロセッサ構成

プロセッサは、実行できる計算の種類と、制御フロー、データ転送、およびプロセッサ構成へのアプローチ方法が異なります。

たとえば、一部のAVRプロセッサは乗算も除算もできません。一方、すべてのx86プロセッサーは可能です。ご想像のとおり、乗算や除算などのタスクに必要な回路を削除すると、プロセッサがよりシンプルで安価になります。これらの操作は、必要に応じてソフトウェアルーチンを使用して実行できます。

x86では、算術命令がオペランドをメモリからロードしたり、結果をメモリに保存したりできます。ARMはロードストアアーキテクチャであるため、メモリにアクセスするための専用の命令がいくつかあります。一方、x86には専用の条件分岐命令がありますが、ARMでは事実上すべての命令を条件付きで実行できます。また、ARMではほとんどの算術命令の一部としてビットシフトを実行できます。これらの違いは、パフォーマンス特性の違い、チップの内部設計とコストの違い、アセンブリ言語レベルでのプログラミング手法の違いにつながります。

結論

ユニバーサルアセンブリ言語を使用できないのは、アセンブリコードをある命令セットから別の命令セットに適切に変換するには、コードを最初から設計し直す必要があるためです。コンピューターではまだできません。

DWによる素晴らしい回答に追加します。1つのアセンブラーが必要な場合は、すべてのアーキテクチャを維持し、それらの間で完璧なトランスレーターを作成し、何をしているかを完全に理解する必要があります。
アーキテクチャごとに高度に最適化されたコードの中には、最適化を解除し、より抽象的なレベルで理解し、互いに最適化する必要があるものがあります。
しかし、これが可能であれば、完璧なCコンパイラが得られ、純粋なアセンブリで記述することはまったく有益ではありません。
アセンブラーを使用する主なポイントはパフォーマンスです。これは、最近のコンパイラーでは絞り込めません。
そのようなプログラムを書くことは、既存のコンパイラよりもさらに難しく、作成されているすべての新しいアーキテクチャを維持することはさらに難しくなります。
「1つだけ」のプログラムの場合、完全な後方互換性も意味します。

マイクロソフトは、MSILを中間アセンブリ言語として発明しました。プログラムはC＃またはVB.NetからMSILにコンパイルされます。実行時に、MSITは、JITコンパイラーを使用して、MSILを実行していたマシンのマシンコードにコンパイルされました。MSILを含むファイルは、プログラムを開始するためのX86の先頭にいくつかの指示がある.EXEファイルでした。ARMプロセッサでは、プログラム名の前に「mono」という単語を入力して実行します。

前述のように、LLVMはこれまでのところこれに最も近いものです。本当に普遍的な言語に対する大きな障壁は、暗黙のトレードオフに関連する基本的な違いです：並行性、メモリ使用、スループット、レイテンシ、および電力消費。明示的にSIMDスタイルで記述した場合、使用するメモリが多すぎる可能性があります。明示的にSISDスタイルで記述すると、次善の並列化が行われます。スループットを最適化すると、遅延が発生します。シングルスレッドのスループット（クロック速度など）を最大化すると、バッテリーの寿命が短くなります。

少なくとも、コードにはトレードオフの注釈を付ける必要があります。最も重要なことは、言語がコンパイラに論理的な矛盾を最適化および検出するための多くの余地を与える優れた代数/型プロパティを持つことです。

次に、未定義の動作の問題があります。C言語とアセンブリ言語の速度の多くは、未定義の動作によるものです。実際に発生する未定義の動作を認める場合、それらを特別なケースとして処理することになります（つまり、アーキテクチャおよびコンテキスト固有のハック）。

おそらくあなたが探しているのは、誰もがコマンドの記号に同意するユニバーサルターニングマシン表記です。（https://en.wikipedia.org/wiki/Universal_Turing_machine）

Turning Acceptable言語を基になるベンダー固有のマシンコードに翻訳し、コンピューターと呼ばれるもののためにビルドされる「アセンブラー」。

The Art of Computer Programmingには、これがどのように見えるかの例があります。

しかし、「すべてのコンピューターで使用できる市販の汎用言語ではない理由」という質問を考えてみてください。最も支配的な影響は次のとおりです。（2）異なるブランドのマシンとベンダーとの間の経済性、提供、非互換性は、ビジネス戦略であり、マシンを設計するための限られたリソース（時間/お金）の結果です。

仮定：高レベル言語L1を低レベル言語L0にコンパイルおよび最適化することは、高レベル言語L2（L1よりも高い）をL0にコンパイルおよび最適化するよりも簡単です。L2からL0へのコンパイルよりもL1からL0へのコンパイルの方が最適化されたコードを生成できるという意味で簡単です。

この仮定はおそらく正しいと思うので、ほとんどのコンパイラは低レベルの中間言語（IR / LLVM）を使用しているのでしょう。

これが当てはまる場合、低レベル言語L0を使用し、L0を他の低レベル言語に翻訳するコンパイラーを作成します。たとえば、MIPS命令セットを使用して、x86、arm、powerなどにコンパイルします。

-タウフィク