Microsoft が Windows を ARM チップセットに移植したと聞きました。
プログラムを別のチップセットに移植するとはどういう意味なのだろうと思いました。Java プログラマーとして、低レベルの詳細についてはあまり知りません。
単純に、Windows は C、C++、および C# の混合で書かれていると思います。ARM には C および C++ コンパイラが既にあると確信しているので、これらのコードはこれらのコンパイラを使用してのみ再コンパイルする必要がありました。C# には .NET インタープリターが必要です。これは低レベル言語でも記述でき、理論的には ARM 固有の C または C++ コンパイラーで再コンパイルできます。
もちろん、手順がそれほど単純ではないことはわかっているので、そのような手順を困難にする可能性のある理論上の制限、考えられる問題などについて学びたいと思います。
注：質問は、私が言及した例に固有のものではありません
コンピュータプログラムは、本質的にかなり異なる傾向があります。ささいな "hello world!" を実行できます。たとえば、本格的な OS を使用することもできます。
「拡張マシンとしてのオペレーティング システム」および「リソース マネージャーとしてのオペレーティング システム」という古典的な定義 (Tanenbaum による) を持つ OS は、多くのことを提供する必要があります。
OS がリソース マネージャーとして機能する必要がある場合、OS は、起動、割り込み、I/O、セキュリティ モードなどの機能を制御する基盤となるマシンの必要最低限の部分で実行されているだけです。Windows のソース コードを調べて確認することはできませんが、 x86 と ARM アーキテクチャの両方で既に実行されているオープン ソースの競合他社 (Linux) を見ると、これらの側面の違いは何ですか。
Linux では、異なるアーキテクチャのサポートはarchディレクトリにあります。たとえば、x86ディレクトリとARMディレクトリがあります。そこにあるディレクトリ名を確認するだけでも、必要な作業 (ブート、電源、メモリ管理など) に関するヒントが得られると思います。
ARM と x86 の世界にはかなりの違いがあります。x86 では、ほとんどすべてが標準化されており ( IBM PC 互換について聞いたことがありますか?)、多くのベンダーがアーキテクチャのクローンを構築しています。それとは対照的に、ARM エコシステムでは、ARM 会社自体が単なる IP プロバイダーであり、すべてのベンダーが互いにわずかな違いから大きな違いを持っています (mach で始まる arch フォルダーのサブディレクトリ名を確認してください - これはマシン用、または plat - それはプラットフォーム用です)。 . ARM では、 UEFIを使用した最近の開発の直前に BIOS のようなものはありませんでしたが、これはまだ大規模に実装されていません (BIOS が良いとも悪いとも言いませんが、単なる例です)。
Windows をあるべき姿にする OS の「拡張マシン」の役割については、移植は比較的容易なはずです。これは主に、ハードディスク パーティション「c:」の呼び出しなどの機能に関するものです。読み取り専用または非表示などのファイル アクセス許可を持ち、Win32 API などのコア API をほぼ機能させます。繰り返しますが、これは単純ではありません。
私は、品質と市場投入までのスピードを確保するために、MS が Linux の非常にオープンな世界と比較して、どの種類の ARM マシンで Windows がどの種類の周辺機器で実行できるかを厳密に定義することを期待しています。
これらは、私が想像できる問題の 2 つの大きなトラックですが、ターンごとに次のような小さな問題が発生する可能性があります。ARM は 32 ビット RISC アーキテクチャであり、char は符号なしであり、最近のハイエンド ARM コアでさえ整数除算をサポートしていません (パフォーマンス?)。
オペレーティング システムのコードの大部分は C で記述されていますが、アセンブラで記述されている部分もかなりあります。これを新しいプラットフォームに移植する必要があります。これのいくつかは、より効率的であるためアセンブリです (memcpy など) が、同等の C 命令がないため (システム コールの作成やスピンロックの正しい処理など)、いくつかのアセンブリが記述されます。これはすべて移植する必要があります。
オペレーティング システムもハードウェアに直接アクセスし、オペレーティング システムが動作するために不可欠なタイマーなどのハードウェアの小さなサブセットがあります。これらはすべて移植する必要があります。
メモリ管理ユニット (MMU) を必要とするプロテクト モードのオペレーティング システムでは、MMU 処理を行うコードを移植する必要があります。
これらのほとんどは、オペレーティング システムの残りの部分からある程度抽象化されますが、これらの抽象化の一部は、特定の仮定に基づいている場合があります。この場合、これらすべてを機能させるために、これらの指示を修正する必要があります。
次に、新しいハードウェアに移植する必要がある大量のドライバーがあります。
問題は異なりますが、一般的に次の領域に分類されます。
非標準機能が使用されている場所。たとえば、ブロック内の実行可能コードの後に変数を宣言することは、ANSI C では有効ではありませんが、C99 および C++ では有効です。ただし、Microsoft コンパイラは C99 をサポートしていません。これに関連して、標準でカバーされていない場所があります。たとえば、プロセスの作成 CreateProcess v. fork/exec、シグナル処理などです。
プログラマーは間違った仮定をします。たとえば、alongが 32 ビットであるとします。これらは、見つけて修正する本物のブタになる可能性があります。
コンパイラが規格に準拠していません。最近ではあまり一般的ではありません。より一般的なのは、一部のプラットフォームでのライブラリの実装の欠如です。もちろん、基準は完全ではありません。同じ基準でも異なる解釈が存在する場合があります。
純粋なアーキテクチャの違い: たとえば、ビッグ エンディアンとリトル エンディアンの問題、ファイル名の形式など。