
Linux/Unix では 64 ビットへの移行はどのように処理されましたか? Windows の世界ではまだ問題があるようですが、*nix の世界ではどのように処理されたのか興味があります。
答え1
カーネルを64ビット化するために必要な作業は、長い昔は DEC Alpha システムを使用していました。しかし、プログラムは別の問題です。
これまで私が目にしてきた一般的な見解は次のようです。
- バイナリが混在するシステム用のディレクトリ
/lib
を分離する/lib64
- 64 ビットとしてコンパイルします。コンパイルが失敗した場合は、ソースが 64 ビットにクリアされるまで 32 ビットとして再コンパイルします。
それ以外では、32 ビットと 64 ビットの混在ビルドによる「問題」はほとんど発生しません。
答え2
Windowsと*ixは移行に異なるデータモデルを使用しました。これはUNIX.orgページ少し古いですが、トレードオフの概要がよくわかります(これはlong long
後にC99に追加され、少なくとも64ビットであることが求められました)。ウィキペディアの記事同じトピックについて。UNIX.org の記事の最後で主張されているように、ほとんどの UNIX 系システムは LP64 を採用しており、つまりlong
、、、long long
およびポインタはすべて 64 ビットです。
Windows は LLP64 データ モデルと呼ばれるものを採用しました。これは、long long
とポインターのみが 64 ビットであることを意味します。 は 32 ビットのままです。その理由の 1 つは、単に に収まると想定されlong
ている壊れたコードを調べて修正したくなかったからです。long
int
答え3
Linux ディストリビューションは大部分がオープンソースであるため、移行はすでに大部分が完了しています。独自のソフトウェア (Skype など) を使用しない限り、何の不都合もなく純粋な 64 ビット システムを実行できます。
しかし、私の意見では、本当の違いは、UNIX 対 Windows というよりも、独自仕様対オープン仕様です。通常、最初に移植されるのはオープン ソース ソフトウェア (ボランティアが何かを再コンパイルする必要がある - おそらくコンパイルの問題を修正するため) - または、ほとんどの場合、まったく移植されずに再コンパイルされるだけ ;) - であり、独自仕様は最後に移植されます。
さらに、Linux ではリポジトリがあるため、インストールは自動的に処理されます。64 ビット版または 32 ビット版を選択する必要はありません (システムが自動的に選択します)。Windows では、プログラムがダウンロードされ、64 ビット版と 32 ビット版が別々に用意されます。
- サーバー上のファイルのサイズが2倍になります
- ユーザーは自分のバージョンを知っている必要があります。あるいは、何かが違うことさえ知っている必要があります。
Windows バイナリが通常 32 ビットであるのは、これが理由だと思います。これは、万能であり、すべての人が 64 ビット バージョンに移行しているわけではないからです。
答え4
実際に、ACM Queue の「The Long Road to 64-bits」を試してみてください。 http://queue.acm.org/detail.cfm?id=1165766 これは後に Communications of the ACM で取り上げられました。最初の 64 ビット マイクロは MIPS R4000 で、1992 年第 1 四半期に SGI Crimson で出荷され、その年の後半に Dec Alpha が出荷されました。
R4000 は最初は 32 ビット モードで実行されていましたが、後に 64/32 モード (つまり、64 ビット OS、64 ビットまたは 32 ビットのユーザー コード) で実行されました。Alpha では常に UNIX が 64 ビットのみで実行されていました (32 ビット アプリケーションのインストール ベースがなかったため、これは合理的な選択でした)。
1990 年代後半、SGI は、XFS が Linux に移植された頃 (Linux は 64 ビットを本当に必要としていた)、Linux を 64 ビット化 (Itanium 上で実行) する取り組みに貢献しました。