286上のLinux？

私は286を所有しておらず、Linuxを実行するつもりもありません。ただし、286にはプロテクトモードがあるため、Linuxには386 CPU以上が必要であると頻繁に述べられているのはなぜですか？

http://tuxmobil.org/286_mobile.htmlから、LinuxのELKSバージョンは286で実行できるようですが、これは正しいですか？286 CPUでカーネルを実行できるようにするために、（もしあれば）何を変更しましたか？

現在、386用にコンパイルされたカーネルは286 CPU（16ビット）で実行できないことを理解しています。私の質問は、なぜ標準Linuxカーネルを286用にコンパイルしてから286で実行できないのかということです。LinuxにはハードウェアVM86サポートが必要ですか？

286プロテクトモード（PM）は、386が提供するものと根本的に異なります。286 PMをプロトタイプと考えてください。これには多くの欠点があり、ほとんど誰も使用していませんでした。また、386全体が完全に再設計されました。

フラットメモリモデルを使用せず、リアルモードのようなセグメントモデルを使用したため、一度に64kBを超えるブロックのメモリにアクセスするにはフープをジャンプする必要がありました。

当時利用可能なすべての（MS-DOS）プログラムとは完全に互換性がなかったため、PMにアクセスすると、使用していたプログラムを使用できなくなりました。

また、PCを再起動しない限り、保護モードを再び終了することはできなかったため、製造元はRAMにフラグを設定し、キーボードコントローラーに魔法の値を書き込むなどの創造的なソリューションを考え出しました。機械。BIOSが最初に行うことは、POSTルーチンを実行する代わりに元のプログラムにジャンプしてフラグを以前に設定し、元のプログラムが「exited」PMを実行し続けることを可能にすることです。

つまり、286 PMを使用すると、多くのトリックなしで通常のDOSプログラムを実行できなくなります。DOSプログラムしかなかった時代には、PMを使用する努力はまったく価値がありませんでした。

そのため、286 PMを使用しない場合よりも286 PMを使用する方が複雑になり、EMSとXMSを使用して追加のメモリにアクセスすることになりました。286のマザーボードの多くは、EMSのチップセットをサポートしているため、PMを必要とせずにすべての追加システムメモリを使用できます。

Intelはこれらの欠点を認識し、386でまったく新しいPMを製造しました。フラットメモリモデルにより、最大4GBのチャンクでメモリに簡単にアクセスできます。CPUは2、3の指示でPMに出入りできるので、面倒な再起動プロトコルは必要ありません。VM86は、ほとんどの場合、PMを終了する必要さえなく、PMにいる間にDOSプログラムを実行できることを意味します。

これらのすべての改善は、386 PMの機能が向上しただけでなく、互換性も大幅に向上したことを意味します。

つまり、286保護モードと386保護モードで共通しているのは名前だけです。これが、PMオペレーティングシステムが通常386以降である理由です。286 PMのサポートの追加は完全に独立した取り組みであり、まったく異なる386 PMと共有できるコードはほとんどないか、まったくありません。

対照的に、386 PMは最後の32ビットCPUまでほとんど同じように機能し、さらに64ビットCPUで32ビットソフトウェアを実行する場合でも機能します。

カーネルにはアセンブリで記述された部分があり、286をサポートするためにそれらを書き直す必要があります。

ELKSについては、FAQでLinuxカーネルのサブセットであると指摘しているため、おそらく絶対必要なものだけを移植しました。

私の質問に対する本当の答えはこれだと思います：

すべての主要なCPUアーキテクチャ（またはその主要な改訂版）には、Cコードに加えて、いくつかのアセンブリサポートコードが必要です。

GCCを使用してLinuxカーネルを16ビット286マシンコードにコンパイルしても、重要な16ビット286互換のアセンブリコードはまだありません。

言い換えれば、カーネルはせいぜい部分的にしか構築されないということです。アーキテクチャ固有のアセンブリコードは、そのアーキテクチャ用に記述されていないため、アセンブルに失敗します。

これに基づいて、これはまさに286またはその他のアーキテクチャでLinuxを実装するときにELKSや同様のプロジェクトが行うこととまったく同じであると想定しています-欠落しているアセンブリサポートコードを実装します。

80386はメモリセグメンテーションに加えてページングをサポートしますが、286はメモリセグメンテーションのみをサポートします。Linuxはページングサポートに大きく依存しています。つまり、基本的にすべてのセグメントレジスタを0に設定し、ページングを使用してアプリケーションを管理するフラットメモリスキームを使用します。Linuxを286に移植するために、基本的なメモリマネージャーは、ページングなしでセグメントモードで動作するように完全に再設計する必要があります。

LinuxにはハードウェアVM86サポートが必要ですか？

私は、アセンブリ男ないんだけど、によると、この：

8086アーキテクチャの32ビット拡張の元の実装である80386命令セット、プログラミングモデル、およびバイナリエンコーディングは、すべての32ビットx86プロセッサの共通分母であり、x86、IA-32、またはi386と呼ばれます。 -コンテキスト、状況に応じたアーキテクチャ。

386 は286からの拡張された命令セットを表しているため、ポートがどれほど難しいかは誰にもわかりません。明らかに、誰もそれを試してみませんでした...十分にそれについてELKSの人々に尋ねることができると思います。

最大の理由は、元のGNUプロジェクトが小さなものをサポートすることを気にするのではなく、32ビットマシン（1980年代半ばのUnixワークスタトンなど）を目指していたため、GNUツールチェーン全体が16ビットコード生成に適していないことです。GCCが286のプロテクトモードコードを生成する能力を持っていた場合、Linuxカーネルを使用する初期のアセンブリが重いセグメントを286に移植することは、他のどの移植ターゲットよりも簡単だったでしょう。しかし、GCCを286保護モードに向けることは、時代遅れのプロセッサをサポートするための巨大なプロジェクトだったでしょう。

最近、Linuxカーネルは386をサポート対象プラットフォームとして放棄し、LinuxカーネルはIntel 286プロセッサをサポートしていません。80286はブートに必要な32ビットCPUではありません。

Linux x86は16ビットプロセッサであり、Linux x86は32ビットプロセッサを必要とするため、80286に簡単にバックポートできません。

より具体的には、286のレジスタはまだ16ビット幅でした。EXレジスタは使用できませんでした。また、メモリセグメントとオフセットはまだ16ビット長でした。プログラムは、依然としてニア/ファーコードとデータを処理する必要がありました。

これは、Linux / 286がLinux / 386とは根本的に異なるカーネルとユーザーAPIを必要とすることを意味します。すべてのアセンブリソースファイルと多くのCソースファイルを書き換える必要があります。Win16とWin32のプログラミングの違いに似ています。

つまり、GCCに異なるCPU用にコンパイルするように指示することはできません。16ビット環境では、すべてのコードを書き直す必要があります。

Linuxを80286で実行するための標準的な方法は、仮想マシン内で実行することです。これがFabrice Bellardがここでやったことです。仮想マシンを自分で実装するか、ポート1を実装する必要があります。