「No mode bit」のData General MV / 8000の利点
私は、Data Generalのチームが新しいマシン(コードネームは「Eagle」、後にMV / 8000と名付けました)を設計するTracy Kidderの「The Soul of a New Machine」を読んでいます。これは、以前のアーキテクチャ(16ビットEclipse)の32ビット拡張です。進化しているテーマの1つは、モードビットを備えたマシンを作成したくないことと、これに成功したことです。 ただし、これが技術的にどのように達成されるかは省略し、モードビットのないマシンを作成することがそれほど魅力的だった理由についても触れていません。この本は技術書ではないため、詳細が多少歪んでいる可能性があります。ただし、この本を読んでいると、「モードビット」ソリューションが当時は一般的であり(したがって実現可能である)、見た目上の理由からエンジニアには魅力がないと見なされていたように感じます。この本はまた、モードビットなしでデザインを作成することは非常に困難な作業のように思われ、この特定のチームによって何らかの形で克服されました。 私はそれがどのように達成されたかについてのこの説明を見つけました: http://people.cs.clemson.edu/~mark/330/kidder/no_mode_bit.txt 基本的には、以前使用されていなかったオペコード空間の部分を新しい命令に使用することのようです。私はそれが「それだけ」だったことに少しがっかりしたことを認めなければなりません。また、これでも未解決の質問がいくつか残っていると思います。 まず、16ビットプロセスは32ビットアドレス空間にどのように存在しましたか。それは、32ビット拡張を「モードビットなしで」作成する際の重要な課題だと思うからです。一方、命令セットの拡張は比較的一般的な作業です。どのようにして起こったのかについての説明がないので、16ビットコードがいつものように単にメモリにアクセスすると想定することができます。おそらく、あるタイプのメモリの仮想化/バンクビュー(新しいCPUレジスタが最初のアドレスの場所を制御する)を見るかもしれません。そんな感じ。しかし、それ以上のものがあるかどうかはわかりません。その場合、一種の「モードビット」ソリューションであると主張することができます。16ビットモードのプロセスは、CPUに追加された特別な機能により、他のプロセスと並行して実行できます。 次に、モードビットのないマシンを作成することがなぜそれほど魅力的だったのでしょうか。この本で宣伝されている利点の多くは、顧客が古いソフトウェアを実行したいと思ったことです。ただし、モードビットを使用する目的は下位互換性を維持することなので、これはモードビットに反するようには見えません。AMDがx86を64ビットに拡張したとき、少なくとも「モードビット」という言葉に対する私の理解によれば、AMDが行ったことは正確にモードビットを追加することでした。CPUを64ビットモードにする特別なビット。また、プロセスを64ビットモードの「サブモード」で実行させるもう1つのビット(32ビットアプリケーションとの互換性を有効にするため)。サブモードの本質は、CPUが命令ストリームを古い32ビット命令として解釈するが、行われた32ビットメモリアクセスは新しいページテーブル形式(64ビット対応オペレーティングシステムによるセットアップ)を使用して解決され、最終的には完全な物理アドレス空間にマッピングされます。また、32ビットのコードは64ビットのコードに取って代わられます。Data Generalソリューションと同様に、これにより、32ビットプログラムを64ビットプログラムの下で実行することもできました(DGの場合は、16ビットと32ビット)。したがって、顧客の観点から見ると、まったく違いがないように見えます。したがって、唯一の利点は実装にあり、設計を簡素化することでしたが、この本はそれが問題であるように聞こえません。モードビットはその時点でも一般的であると思われるためです(そして、それ以降のアーキテクチャでもx64ケースが示すようにそれを採用しました)。 私が見逃したものがあると私は確信しているので、誰かがこの「モードビットなし」の設計の技術的な詳細と長所についてもっと議論できたら素晴らしいでしょう。