命令キャシュというか命令キュー
８ビットCPUの時代はシンプルに、命令の取り込み、解釈、実行と順番に実行していたので、処理能力を上げるためには、それぞれの段階、つまりクロック周波数を上げれば速くなるというものでした。クロック周波数を上げるには基本的には集積度を上げる必要があって、簡単に出来ることではありません。
そこで、クロックを上げる以外の方法がいろいろと編み出されたのです。パイプラインであるとかキャッシュなど、今では当たり前になったものが多いのですが、おそらく最初の工夫は8086の命令プリフェッチではないかと思います。
8086 - 今も生き残るアーキテクチャ
パイプライン処理
キャッシュ (コンピュータシステム)
もちろん８ビットから16ビットになったことによって、データバスが大きくなり１度の処理で１バイトではなく１ワード（２バイト）をメモリから読み出すことが出来るようになったことも大きく影響します。ただx86の機械語命令はバイト単位なのでワード単位で読み出すと、余分なバイトまで読み出してしまうことがあります。これを有効に活用したとまでは言い切れませんが、メモリからの命令読み出しと命令の解釈を分離するためにも３命令分の命令をキューに溜めておくようになっていました（8088は２命令分だったようだ）。
訴訟合戦が勃発、高性能80486で市場を確保
8086は命令によっては、かなり複雑な処理をするものもあり、その多くはマイクロコードというCPU内部の回路で実行される特別なソフトウェアで実装されていて、命令によっては実行するのに必要なクロック数がかなり必要なものも多くなりました。このためにも少しでも早く実行すべき命令を取り込んでしまいたかったのも確かでしょう。
このように本当のデータと仮のデータが発生すると、キャッシュなどで聞いたことがあると思いますが、これらの内容が一致しない状況が発生して、気をつけないと時折、謎の挙動を示すという事態があり得るようになりました。8086の場合、命令を読み出すべきメモリアドレスを生成するためのセグメントレジスタ(CS)を変更したときが鬼門で、ドキュメントで示されたような手順で更新しないと、意図しない命令を実行してしまうことがありました。
x86のリアルモードから保護モードへの移行について
これは一例で、他にもCSを更新するときには、いろいろ配慮が必要だった記憶があります。まあセグメントレジスタの導入が良かったのか悪かったのかは意見の分かれるところですが、64Kの壁を作ってしまったのはコードを書く人からは苦労しかありませんでした。
86なんて忘れてしまったので、思い出したいという人に良さそうなアーカイブを見つけました。ハードウェアの構成からコードの書き方まで書いてあります。
8086マシン語秘伝の書
ザ 8086ブック 16ビットマイクロプロセッサ 8086・8088の使い方 1982年
x86も286からプロテクトモードが出来たのですが、64Kの壁は変わらずで、386でようやくリニアなアドレス空間が手に入ります。その頃には命令パイプラインも実装され、486からはキャッシュメモリが搭載されたりFPUも内蔵するなど、表に出ないところでの進化が続きました。そうなると同じコードがどのくらいのパフォーマンスがあるかの判断も難しくなるのですが、もうそんなことを気にしないでも良いほどクロック周波数は高くなったのは確かです。
ヘッダ画像は、いらすとやの以下の画像を使わせていただきました。
https://www.irasutoya.com/2020/09/blog-post_44.html
この記事が気に入ったらサポートをしてみませんか？