Cは新しいアーキテクチャ用の移植可能な言語ですか、それともISAに固有ですか？
C言語はどのようにして命令セットに移植できますか（新しいアーキテクチャを意味します）？新しいアーキテクチャごとに新しいCコンパイラを作成する必要がありますか？
一般に、すべての新しいアーキテクチャには、Cコンパイラの新しいポートが必要です（残りのCツールチェーンとともに）。
通常、これは、新しいアーキテクチャー用にCをコンパイルするための既知のアーキテクチャーでの「クロスコンパイラー」の開発から始まります。
（コンパイラー自体が、新しいアーキテクチャー用にソースからコンパイルされるものになる可能性があります。）
関連する新しいアーキテクチャであっても、新しいアーキテクチャを利用するにはコンパイラに多くの更新が必要です。たとえば、8086 Cコンパイラおよび80486アーキテクチャ用に変更
基盤となるハードウェア間の変更（8ビット、16ビット、32ビット、64ビット、128ビットなど）では、新しいアーキテクチャを利用するためにコンパイラを変更する必要があります。異なるバス（ISA、s80など、さまざまなバス機能を利用することができますが、通常、これは最初の考慮事項ではありません。より重要な考慮事項は、新しいCPUがサポートできる命令と「パイプライン処理」の処理方法、およびALU/etcユニット（および各ユニットの数）は、新しいCPUで使用できます。
C言語がどのような命令セットにも移植可能である（新しいアーキテクチャを意味する）。
そうではありませんが、Cはほとんどの合理的な命令セットに移植可能で、既存の命令セットに近いです。
架空の反例として、3進数（バイナリではない）または10進数を使用してコンピュータアーキテクチャを定義する場合があります。どちらも過去に発生しました（1960年代： IBM/162 は10進数、ロシア語 Setun は3進数でした）。これらのマシンでは、C [クロス]コンパイラはまったく不可能です。過去の LISPマシン （または Smalltalk ones）または Rekursiv または iAPX432 マシンでは、Cは非常に困難です（移植はほとんど不可能です。現在の [〜＃〜] safe [〜＃〜] Darpaプロジェクトは、Cに適さないアーキテクチャを定義しています。
実際には、バイト（8ビット）、バイトアドレッシング、 Harvard または Von Neumann アーキテクチャの可用性が、妥当なCコンパイラにほぼ必要です。 CおよびCでコーディングされた多くの実用的なプログラムは、ほとんどの32ビットまたは64ビット（または仮想の128ビット）のマシンに移植できます（24ビットまたは48ビットのマシン、または9ビットのマシンに移植するのははるかに困難です） -bits charおよび36ビットワード（原則として実現可能であっても）。
もちろん、今日新しいアーキテクチャを定義する場合（例 [〜＃〜] riscv [〜＃〜] または [〜＃〜] mill [〜＃〜] ） 、あなたは実際にそれを多かれ少なかれC互換であると定義し（そしていくつかのPOSIXのようなOSを実行することができるいくつかの既存のプロセッサに近い）そしてあなたは設計します（そしてコードはしばしば [〜 ＃〜] gcc [〜＃〜] または Clang ）、C クロスコンパイラ そうでない場合、アーキテクチャが根本的に異なる場合は、そのためのコンパイラとオペレーティングシステムの開発を検討する（そして予算を立てる）必要があります。
また、特定のプログラム（Linuxカーネル、Firefoxブラウザなど）が新しいアーキテクチャに簡単にported できるかどうかもわかりません。
ソフトウェアの移植性 はyes/no機能ではないことに注意してください（ endianness 、 data alignment 、 cache coherence と考えてください） on マルチコアプロセッサ 、実装固有のコード、 asm命令 、 未定義の動作 、ライブラリの可用性、オペレーティングシステムAPI- Win API は [〜＃〜] posix [〜＃〜] ）とは大きく異なります。 移植性のあるソフトウェアはなく、特定のコンピュータに移植されたソフトウェアだけです。 Linuxディストリビューション for x86-64でも、さまざまな異なる パッケージマネージャー があり、同じソースコードをコンパイルするには、異なるディストリビューションで異なるパッケージが必要になる場合があります。たとえば RefPerSys は フリーソフトウェア - C++ 17 にコード化されており、Linuxでは Qt5 -を使用しています貢献しますが、名前が異なるさまざまなパッケージに依存します（そしてその commit e611de7f は ビルドオートメーション ツールに依存します omake 0.10.3ディストリビューションにパッケージ化されているが、omakeはGPLされている free software ）
新しいアーキテクチャ用にCコンパイラを再度記述する必要がありますか？
はい、それは クロスコンパイラ になる可能性があります。さまざまな例については、 [〜＃〜] gcc [〜＃〜] のソースコードを参照してください。それぞれが1年間のフルタイムの仕事を意味する可能性があります。
はい。命令セットが定義され、マシンコード、アセンブリ言語構文がアセンブラとともに定義されています。おそらくリンカーであり、Cコンパイラの移植の準備ができています。そして、ブートローダー、オペレーティングシステムなどから始めることができます（当然、設計検証の後、またはその一部として）。
まれに、誰もがこの道から外れ、まれに成功します。いつでも無数の言語を移植できますが、汎用プロセッサー用のアセンブラーとCコンパイラーがなければ、それほど遠くまで到達できません。
汎用プロセッサでない場合は、アセンブラで十分です。
新しいアーキテクチャごとにCコンパイラを作成する必要はありません。たとえば、 LISP Machine および Java VM は、Cコンパイラがなくても非常にうまく機能します。
しかし、本当にそうしたいのであれば、Cはこれらのアーキテクチャでも移植可能です Turing complete 。
一般的なCフレンドリーなアーキテクチャーでよく使用されるアプローチは、C クロスコンパイラー を記述して使用することです。その後、クロスコンパイルから独立したい場合は、Cコンパイラをクロスコンパイルしてできれば、新しいアーキテクチャ上にネイティブCコンパイラがあります。
新しいISAの機能が既存のものと類似している場合は、多くの作業を節約できます。たとえば、LLVMに新しいバックエンドを追加して、多くのプログラミング言語を無料で入手できます。
これを行うには、ISAの基本的な詳細をコンパイラーに記述します（整数、ポインター、浮動小数点数のビットサイズ）。Cコードは、次のものを含むいくつかの中間言語にコンパイルできますアセンブラーに非常に似ていますが、ISA独立しています。次に、この中間言語をISAに変換するバックエンドを作成する必要があります。
1つのバックエンドを作成することで、フロントエンドでサポートされているすべてのプログラミング言語を無料で入手できます。
ここで、ISAが、3進数、クレイジーなWordやポインタサイズなど、あまりに異なっている場合、問題が発生する可能性があります。
詳細については、Chris Lattnerによる次の記事を確認してください。 https://aosabook.org/en/llvm.html