「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ケースが示すようにそれを採用しました）。

私が見逃したものがあると私は確信しているので、誰かがこの「モードビットなし」の設計の技術的な詳細と長所についてもっと議論できたら素晴らしいでしょう。

その答えは、Data General Managementの社長であるEd deCastroが、特に次世代CPUを設計するためにノースカロライナにエンジニアのチームを設立したことです。マサチューセッツ州のチームである彼にサポートと段階的な拡張のタスクを割り当てました。3回、主要な新しいアーキテクチャを提案しました。毎回非常に実用的なモードビットを使用し、それをささやかな増分拡張として説明しました。エドは毎回、私たちの変装を見て、提案を拒否し、ノースカロライナチームが成功することを期待していました。Edは、私たちが提案を偽装しようとした方法に関係なく、モードビットがあればそれが新世代のアーキテクチャであることを知っていると信じていました。そのため、効率が悪くなったとしても、モードビットのない新世代のアーキテクチャを提案する必要がありました。それがエド・デカストロを通り抜けた方法です。新しい機械の魂を参照してください、

$2^{16}$

モードビットを使用する場合、プログラムが16ビットか32ビットかを判別するために古い16ビットOSを変更し、プログラムを起動する前にモードビットを適切に設定する必要がありました。

実際には、MV / 8000には実際にモードビットがあったようです。マークスマザーマンのクレムソンのWebページの他の場所で、彼はデータジェネラル、ECLIPSE MV / 8000 Principles of Operation、1980を投稿しました。付録E（369ページ以降）を見ると、MV / 8000に2つのまったく異なるページテーブルメカニズムがあったことがわかります。MV / 8000との下位互換性がある特定のマシンはC / 350であり、C / 350には特定の16ビットメモリ割り当ておよび保護ユニットがあり、そのユニットを制御する特定の方法がありました。32ビットの論理から物理への操作では、代わりにアドレス変換ユニットをオンにします（第3章で説明されている31ページ以降）。

実際には、32ビットモードで16ビット命令を実行すると、論理アドレスの上位16ビットが0に設定されるように指定されています。 16ビットモードで32ビット命令を実行したときのアドレスの16ビットですが、マニュアルをざっと見ているだけでアドレスを見つけることができませんでした。

つまり、モードビットが良いことか悪いことかという問題ではありません。16ビット命令と32ビット命令を区別するためにモードビットを使用する特別な理由がなかったというだけのことです。16ビット命令は16ビットの論理アドレス（上位16ビットを0に設定）と16ビットレジスタを使用し、32ビット命令は32ビットの論理アドレスと32ビットレジスタを使用します。古いOSは新しいマシンで「正常に動作」しますが、古いOSで新しいプログラムを実行して新しい命令を試すこともできます。