…何処かに、ＤＣＳその他はあるのだろう、けど。
今もそうかは解らないが、インテル系ＣＰＵは乗算命令とかが、重い（それはどんなＣＰＵでも重いのだが、インテル系は当時、悲しいほどに重かった）。結果、もちろん昔から、乗算の要求等々は、「プログラマーがビット計算を駆使して簡略化する」のが定例には成っていて、そこのアルゴリズムを調整する方が、ハードに実装されてる命令を使うより早くなるのである、アセンブラレベルでは。この辺のチューニングに関して、インテル系はかなり顕著？で、ＲＩＳＣか？と疑うほどに、命令毎に速度差がある。ＡＭＤの方がこの辺均等？と言うか、判断分岐に関しては速いのだが。データの移動に関してはその限りでは無く、インテルＣＰＵはその一点に置いて、他の追随は確かに許さないのだが。ともかくアセンブラレベルの話なら、プログラマーのチューニングが、全体に対して劇的なレスポンスの向上を齎す事は、結構有る訳だが。
…この疑問？は要するに、「それでは説明出来ない」程、或いはＤＣＳとかが速い？と言う事なのかもしれない…ともかく何処に有るんだよそれ(-_-;)（←・・・）。
速くなる理由は様々、だ。解りやすい所では「如何に条件分岐命令を外すか？」と言うのは、有る。画面上のドット単位で、「青い所は抜いて合成する」時、実際、いちいちドット単位で”見て”判断せねばならない。この判断命令が”異様”に遅く、これが全体の足を引っ張ってしまう、訳だが。ここをどう簡略化するか？しかし。
そもそも条件分岐命令が、普通のジャンプ命令程度に速ければ良いのでは。
出来るか？と言うと、実は一部で”出来る”場所がある。計算を行った直後、ＣＰＵはその内容に応じてフラグを立てる、訳だが。そのフラグが立って居たら一つずらす、立って無かったらそのまま、と言う処理がどうなるか？と言うと。上から順に実行。
ｎ＝フラグ数値（通常は１、フラグ立ってる時は２）
ｎ番へジャンプ
１番：ジャンプＡへ
２番：ジャンプＢへ
ジャンプＡ
Ａの処理
ジャンプＢ
Ｂの処理
この時、実は「判断命令を使ってない」のだ。「ジャンプさせたい数値ｎに、フラグを加算する」だけで、実は”条件ジャンプ処理が可能”になる。これは何を意味するか？と言うと、「どれだけ複雑な条件判断をさせた所で、データを移動するのと処理速度に差が無い」と言う事を意味する。１ドット単位に、その数値によって異なるデータ変更をする場合も、”単に引き算をするだけ”で良い。この結果、実はＣＰＵ命令の条件ジャンプ命令を使うよりも格段に速くなる訳だ。この意味は大きく、インテル系なら特に？ＣＰＵの速い所”だけ”を効率的に使う事が可能になる（ＣＰＵ命令の半分以上を切り捨てる、使わない事には成るが）。結果的に、或いは劇的な速度向上を齎しうる、が。
…これをやる為には、「むしろエミュレータを創った方が良い」のであって。その、条件分岐が格段に高速化したＣＰＵエミュレータを用いると？全体に対して、格段の速度向上が齎される。「と言う技術は想定はされている」のだが。ともかく？それが想定された性能を持って居たら、低スペックの筈のハードで信じられないアプリが動いていても？何ら不思議は無い、のだが。この時確かに、見た目上エミュレータの性能が、ハードスペックを超えてしまう場合が発生は、する。ただ、本来のポテンシャルを引き出したに過ぎない、そう言う言い方も無い事も無いが。
しかしこの時、ＣＰＵは無理してインテルで有る必要があるのだろうか？アプリ、ＯＳにとっても、「ＣＰＵエミュレータこそがＣＰＵ」であって。更に、ＣＰＵが仮想化されてしまうと、ハードがなんであるか？は更に問題が無くなる。
「…DOS/Vは？」
この時、DOS/Vの危機感は”更に煽られてしまう”訳だが。
大事な事なのだ、「共産主義的な独裁性を抑え込む！」事は。”それ”が、何と言うか、小学生の「ゲームで遊びたい！」的衝動により破壊されかねない事態に、危機感は確かに発生はして。現状、”この辺”を加味してか、上記の技術は一世代前の３２Bit環境でしか実現しては居ない、様だ。６４Bit環境の、リニアに使える膨大過ぎるメモリを駆使する様なアプリは、流石にＣＰＵパワーだけでは実現できず…現在の性能で、何か不足が有るか？と言うと、ゲーム性に関しても、グラフィックに関しても頭打ちな状況は、有って。だからこそ、「パワースタチュー」は現在のベクトルからして何かのアドバンテージをDOS/Vに与える筈、ではあり。しかし。
…ＤＣＳは、この３２Bit枠を守るのだろうか？
気が休まらない。
