アカウント名:
パスワード:
思うのですが、128bitCPUは結構早く出てくるのではないでしょうか。
現在の64bitはAMD64が主流ですが。インテルが頑としてこの名前を使いたがらない、COREアーキテクチャの64bit対応が実にお座なりだったコト等から考えるに、インテルは64bitの主導権を取られたことを「最大の恥部」と捉えているのではないでしょうか。
インテルがこの「恥部」を抹消する為に「128bitCPUを作って(初めは)安くでバラまいて、さっさと普及させればいいんじゃね?」と考えていても、不自然ではないと思います。
そんな背景があるとしたら、128bitカーネル開発に乗り出していても納得出来るのですが。どんなもんでしょうね?
ビジネス的にはそうかもしれませんけど、ユーザ側にメリットがないとなかなか売れませんよね。64bitにはできなくて128bitだとできることってなんでしょうね? アドレス幅も不足しているわけではないし。そんなにたくさん命令セットもいらないような……
SPARCが早い時期から64bit CPUを実用していましたけど、ユーザの目からみると全く目立たなかったですしね……
> 個人が使うようなアプリケーションで128bitのメモリ空間(≠実装メモリ量)を必要とするものなんて考えられない
初代PC-9801の頃には「640KBものメモリを何に使うのかわからない」とか、80386が出た頃には「(80286の上限を超える)16MB以上なんて絶対使わない」とか、ちょっと前だと「4GBのメモリ空間なんて絶対埋まらない」とか考えられていたわけだから、そのうち「昔の人はなんで128ビットのメモリ空間で足りるなんて思ってたんだろう?」とか思われてしまうのではないかと。
そういえば、AMDが286互換で推してるときに「386は本当に必要ですか?」なんて、意見広告みたいなキャンペーンやってたよね。
世の中はあっという間にi386一色になっちゃったけど。
未来なんてわかんないものさ。
「仮想86モードを使ったソフトウェアEMSドライバ」の出現によって、286にはどうやっても勝てない386の優位性が生まれて、それによって286は駆逐された感じでしたね。
当時はDOSな8086用プログラムが主流で、286も386も高速な8086としてしか使われておらず、8086なプログラムを動かす分には同クロックで比べると386より286の方がちょっぴり速かったんだけど、せいぜい数パーセントの差。
ところが、Cバスに挿すようなハードウェアEMSメモリと、386プロテクトメモリを使ったソフトウェアEMSでは、メモリアクセスに数倍の速度差があるという…
80286 機でも搭載メモリを 3MB (本体 1MB + 増設 2MB) にして増設した 2MB をソフトウェア EMS として利用するような事はできていましたよ。 PC-9801DX (80286 搭載機) で ATOK や Vz Editor のために EMS 領域を 128KB 残し、残りを RAM ディスクにして ATOK7L.DIC を置き……とかやってましたし。
プロテクトモード自体は 80286 から持っていましたが、80286 ではリアルモードからプロテクトモードへは遷移できても、プロテクトモードからリアルモードへはリセットが必要という制約があったというのはあります。 しかし仮想 86 モードはプロテクトモードを利用したもので、別にリアルモードへ遷移するようなものではないのでこの点は特に大きな障害という問題ではなかったかと思います。
PC-98 系とかで言えば 286 機はメモリ搭載量が 1MB 以下ばかりであったものの、386 機は最初から 2MB (1.6MB) 積んでいるものが主力となり、ソフトウェア EMS の利用が活発となりやすかった点なども影響としては大きかったかと思います。もちろんメモリの価格低下も要因として含まれるでしょう。 そこらのショップで売ってる PC-98 用内蔵増設メモリ (つまり C-Bus 増設ではないもの) が 1 万円で 1MB から 2MB になったのもこの辺りの過渡期辺りだったと思いました。
C-Bus に差すタイプの増設メモリは普通に C-Bus 経由のアクセス速度が遅かったのが、速度に関する決定的な要因ではないでしょうか。 当時 IO DATA 辺りとかは「増設メモリとしても EMS 専用メモリとしても使えるボード」などを出していましたが、増設メモリとして利用した場合、起動時のメモリカウントで本体に増設されているメモリから C-Bus 上のメモリと切り替わると目に見えてカウントアップの速度が落ちてました。
XMSとEMSを混同されてませんか?
XMSは、80286/386を前提としたプロテクトメモリ活用方法であり、1MB超の8086のバグ的仕様でアクセス(HMA)したり、ドライバのAPIを経由して必要に応じてブロック転送(EMB)したりすることで、8086モードでも1MB超のメモリ空間の恩恵を得られるようにします。
EMSとは「8086モードでアクセスできる1MBのメモリ空間」内に窓(通常、16KB×4ページ)を用意し、そこを通すことで、8086アーキテクチャで1MB超のメモリ空間を提供する技術です。EMS自体は、8086アーキテクチャベースで、その「1MB超のメモリ」がどこにあるかは規定されてません。
で、その実現方法として、上述のXMSのように、ドライバが1MB超と1MB以内のメモリ間でブロック転送をするという「ソフトウェアEMS」なんてのもありましたが、速度的にはページ切替のたびにメモリコピーが発生するのでとんでもなく遅くなりました。それと、1MB下のメモリ空間中の「窓」として、メインメモリを消費する、というデメリットもありました。後述のハードウェアEMSや仮想86ソフトウェアEMSでは、メモリマップ上の未使用部分にEMS用の窓を割り当てますので、メインメモリの640KBはそのまま使えます。
ハードウェアEMSは、汎用拡張スロットに配置したハードウェアで直接「窓」を提供するもの。メモリマップ上にはメモリはには存在せず、バンク切替の影に隠れてます。拡張スロットの遅さから、メモリアクセスが内蔵メモリにくらべ格段に遅いですが、それでも、ソフトウェアEMSよりは、転送が発生しない分高速です。
最後に出てきた「仮想86モードソフトウェアEMS」ですが、、80386のプロテクトモード下の仮想86モードでは、386プロテクトモードのMMU機能を有効にしたまま8086として動作するので、MMUを使って1MB超の「プロテクトメモリ」を8086からアクセスできるEMSの窓に直接配置することができました。これが仮想86モードによるプロテクトメモリを利用したソフトウェアEMS。内蔵の高速なメモリが使えますし、オーバーヘッドもほとんどありません。
この方法は、仮想86モードもMMUも無い80286では、そもそも実現不可能です。
速度を比較すると
386の仮想86モードによるソフトウェアEMS >> Cバスなどの遅い拡張スロットに実装されたハードウェアEMS >> ブロック転送方式のソフトウェアEMS
って感じでした。
あー、そうですね。XMS + EMS でやってましたね。
ただ、C-Bus によるハードウェア EMS は必ずしも 286 によるソフトウェア EMS より遅いとは限りませんよ。「どのように実装するか」がまさにハードウェア依存なので。
使ってた EMS ボードでは 286 で増設したメモリを EMS として利用した方が速かったですから。 それでも FD よりは圧倒的に速いので重宝しました。
ディップスイッチ切り替えると電源をオフにしてもデータが残る RAM ディスクとして使えるとか、そんな高付加価値 (笑) タイプとかだとそんなことになっちゃいますね。
80286搭載PC-9801の場合CPU clockが10または12MHzとC busの最高動作クロック(10MHz)と大差ない速度で動いていたため、ハードウェアEMSでもあまり遅さを感じずに済んでいましたが、80386搭載PC-9801ではCPU clockが16MHz以上とC busのアクセス速度との間に差が出てきたので80386搭載機所有者にとっては遅さが感じられました。
当時PC-9801VX21(80286 10MHz, C-busに4MB RAM増設), PC-9801 note SX(80386SX 12MHz, RAM 1.6MBだったかな?), PC-9801DA2(80386DX 20MHz local busに8MB増設,後にCyrixに載せ替えCPU内部クロックは40MHzに)を持っていたので、このあたりの違いをそれなりに感じてました。
# ここまでBMSの話無し。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
インテルから具体的な話がある可能性 (スコア:4, すばらしい洞察)
思うのですが、128bitCPUは結構早く出てくるのではないでしょうか。
現在の64bitはAMD64が主流ですが。
インテルが頑としてこの名前を使いたがらない、COREアーキテクチャの64bit対応が実にお座なりだったコト等から考えるに、インテルは64bitの主導権を取られたことを「最大の恥部」と捉えているのではないでしょうか。
インテルがこの「恥部」を抹消する為に
「128bitCPUを作って(初めは)安くでバラまいて、さっさと普及させればいいんじゃね?」
と考えていても、不自然ではないと思います。
そんな背景があるとしたら、128bitカーネル開発に乗り出していても納得出来るのですが。
どんなもんでしょうね?
Re: (スコア:3, 興味深い)
ビジネス的にはそうかもしれませんけど、ユーザ側にメリットがないとなかなか売れませんよね。64bitにはできなくて128bitだとできることってなんでしょうね? アドレス幅も不足しているわけではないし。そんなにたくさん命令セットもいらないような……
SPARCが早い時期から64bit CPUを実用していましたけど、ユーザの目からみると全く目立たなかったですしね……
人生は七転び八起き、一日は早寝早起き
Re: (スコア:0)
企業向けだってそうそうあるものじゃないと思うが...............
(少数だが128bitを切望している人がいることは確かだろうけど)
Re: (スコア:1, すばらしい洞察)
> 個人が使うようなアプリケーションで128bitのメモリ空間(≠実装メモリ量)を必要とするものなんて考えられない
初代PC-9801の頃には「640KBものメモリを何に使うのかわからない」とか、
80386が出た頃には「(80286の上限を超える)16MB以上なんて絶対使わない」とか、
ちょっと前だと「4GBのメモリ空間なんて絶対埋まらない」とか考えられていたわけだから、
そのうち「昔の人はなんで128ビットのメモリ空間で足りるなんて思ってたんだろう?」とか
思われてしまうのではないかと。
Re: (スコア:0)
そういえば、AMDが286互換で推してるときに
「386は本当に必要ですか?」
なんて、意見広告みたいなキャンペーンやってたよね。
世の中はあっという間にi386一色になっちゃったけど。
未来なんてわかんないものさ。
Re: (スコア:3, 参考になる)
「仮想86モードを使ったソフトウェアEMSドライバ」の出現によって、286にはどうやっても勝てない386の優位性が生まれて、それによって286は駆逐された感じでしたね。
当時はDOSな8086用プログラムが主流で、286も386も高速な8086としてしか使われておらず、
8086なプログラムを動かす分には同クロックで比べると386より286の方がちょっぴり速かったんだけど、せいぜい数パーセントの差。
ところが、Cバスに挿すようなハードウェアEMSメモリと、386プロテクトメモリを使ったソフトウェアEMSでは、メモリアクセスに数倍の速度差があるという…
Re:インテルから具体的な話がある可能性 (スコア:1)
80286 機でも搭載メモリを 3MB (本体 1MB + 増設 2MB) にして増設した 2MB をソフトウェア EMS として利用するような事はできていましたよ。
PC-9801DX (80286 搭載機) で ATOK や Vz Editor のために EMS 領域を 128KB 残し、残りを RAM ディスクにして ATOK7L.DIC を置き……とかやってましたし。
プロテクトモード自体は 80286 から持っていましたが、80286 ではリアルモードからプロテクトモードへは遷移できても、プロテクトモードからリアルモードへはリセットが必要という制約があったというのはあります。
しかし仮想 86 モードはプロテクトモードを利用したもので、別にリアルモードへ遷移するようなものではないのでこの点は特に大きな障害という問題ではなかったかと思います。
PC-98 系とかで言えば 286 機はメモリ搭載量が 1MB 以下ばかりであったものの、386 機は最初から 2MB (1.6MB) 積んでいるものが主力となり、ソフトウェア EMS の利用が活発となりやすかった点なども影響としては大きかったかと思います。もちろんメモリの価格低下も要因として含まれるでしょう。
そこらのショップで売ってる PC-98 用内蔵増設メモリ (つまり C-Bus 増設ではないもの) が 1 万円で 1MB から 2MB になったのもこの辺りの過渡期辺りだったと思いました。
C-Bus に差すタイプの増設メモリは普通に C-Bus 経由のアクセス速度が遅かったのが、速度に関する決定的な要因ではないでしょうか。
当時 IO DATA 辺りとかは「増設メモリとしても EMS 専用メモリとしても使えるボード」などを出していましたが、増設メモリとして利用した場合、起動時のメモリカウントで本体に増設されているメモリから C-Bus 上のメモリと切り替わると目に見えてカウントアップの速度が落ちてました。
Re:インテルから具体的な話がある可能性 (スコア:2, 参考になる)
XMSとEMSを混同されてませんか?
XMSは、80286/386を前提としたプロテクトメモリ活用方法であり、
1MB超の8086のバグ的仕様でアクセス(HMA)したり、
ドライバのAPIを経由して必要に応じてブロック転送(EMB)したり
することで、8086モードでも1MB超のメモリ空間の恩恵を得られるようにします。
EMSとは「8086モードでアクセスできる1MBのメモリ空間」内に窓(通常、16KB×4ページ)を用意し、
そこを通すことで、8086アーキテクチャで1MB超のメモリ空間を提供する技術です。
EMS自体は、8086アーキテクチャベースで、その「1MB超のメモリ」がどこにあるかは規定されてません。
で、その実現方法として、上述のXMSのように、ドライバが1MB超と1MB以内のメモリ間でブロック転送をするという「ソフトウェアEMS」なんてのもありましたが、速度的にはページ切替のたびにメモリコピーが発生するのでとんでもなく遅くなりました。
それと、1MB下のメモリ空間中の「窓」として、メインメモリを消費する、というデメリットもありました。後述のハードウェアEMSや仮想86ソフトウェアEMSでは、メモリマップ上の未使用部分にEMS用の窓を割り当てますので、メインメモリの640KBはそのまま使えます。
ハードウェアEMSは、汎用拡張スロットに配置したハードウェアで直接「窓」を提供するもの。メモリマップ上にはメモリはには存在せず、バンク切替の影に隠れてます。
拡張スロットの遅さから、メモリアクセスが内蔵メモリにくらべ格段に遅いですが、それでも、ソフトウェアEMSよりは、転送が発生しない分高速です。
最後に出てきた「仮想86モードソフトウェアEMS」ですが、、
80386のプロテクトモード下の仮想86モードでは、386プロテクトモードのMMU機能を有効にしたまま8086として動作するので、MMUを使って1MB超の「プロテクトメモリ」を8086からアクセスできるEMSの窓に直接配置することができました。
これが仮想86モードによるプロテクトメモリを利用したソフトウェアEMS。内蔵の高速なメモリが使えますし、オーバーヘッドもほとんどありません。
この方法は、仮想86モードもMMUも無い80286では、そもそも実現不可能です。
速度を比較すると
386の仮想86モードによるソフトウェアEMS >> Cバスなどの遅い拡張スロットに実装されたハードウェアEMS >> ブロック転送方式のソフトウェアEMS
って感じでした。
Re:インテルから具体的な話がある可能性 (スコア:1)
あー、そうですね。XMS + EMS でやってましたね。
ただ、C-Bus によるハードウェア EMS は必ずしも 286 によるソフトウェア EMS より遅いとは限りませんよ。「どのように実装するか」がまさにハードウェア依存なので。
使ってた EMS ボードでは 286 で増設したメモリを EMS として利用した方が速かったですから。
それでも FD よりは圧倒的に速いので重宝しました。
ディップスイッチ切り替えると電源をオフにしてもデータが残る RAM ディスクとして使えるとか、そんな高付加価値 (笑) タイプとかだとそんなことになっちゃいますね。
Re:インテルから具体的な話がある可能性 (スコア:1)
80286搭載PC-9801の場合CPU clockが10または12MHzとC busの最高動作クロック(10MHz)と大差ない速度で動いていたため、ハードウェアEMSでもあまり遅さを感じずに済んでいましたが、80386搭載PC-9801ではCPU clockが16MHz以上とC busのアクセス速度との間に差が出てきたので80386搭載機所有者にとっては遅さが感じられました。
当時PC-9801VX21(80286 10MHz, C-busに4MB RAM増設), PC-9801 note SX(80386SX 12MHz, RAM 1.6MBだったかな?), PC-9801DA2(80386DX 20MHz local busに8MB増設,後にCyrixに載せ替えCPU内部クロックは40MHzに)を持っていたので、このあたりの違いをそれなりに感じてました。
# ここまでBMSの話無し。
ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより