パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Windows 8には128bit版が登場?」記事へのコメント

  • 思うのですが、128bitCPUは結構早く出てくるのではないでしょうか。

    現在の64bitはAMD64が主流ですが。
    インテルが頑としてこの名前を使いたがらない、COREアーキテクチャの64bit対応が実にお座なりだったコト等から考えるに、インテルは64bitの主導権を取られたことを「最大の恥部」と捉えているのではないでしょうか。

    インテルがこの「恥部」を抹消する為に
    「128bitCPUを作って(初めは)安くでバラまいて、さっさと普及させればいいんじゃね?」
    と考えていても、不自然ではないと思います。

    そんな背景があるとしたら、128bitカーネル開発に乗り出していても納得出来るのですが。
    どんなもんでしょうね?

    • Re: (スコア:3, 興味深い)

      ビジネス的にはそうかもしれませんけど、ユーザ側にメリットがないとなかなか売れませんよね。64bitにはできなくて128bitだとできることってなんでしょうね? アドレス幅も不足しているわけではないし。そんなにたくさん命令セットもいらないような……

      SPARCが早い時期から64bit CPUを実用していましたけど、ユーザの目からみると全く目立たなかったですしね……

      --
      人生は七転び八起き、一日は早寝早起き
      • by Anonymous Coward on 2009年10月09日 23時24分 (#1651975)
        個人が使うようなアプリケーションで128bitのメモリ空間(≠実装メモリ量)を必要とするものなんて考えられない
        企業向けだってそうそうあるものじゃないと思うが...............
        (少数だが128bitを切望している人がいることは確かだろうけど)
        親コメント
        • by Anonymous Coward on 2009年10月10日 0時27分 (#1652002)

          > 個人が使うようなアプリケーションで128bitのメモリ空間(≠実装メモリ量)を必要とするものなんて考えられない

          初代PC-9801の頃には「640KBものメモリを何に使うのかわからない」とか、
          80386が出た頃には「(80286の上限を超える)16MB以上なんて絶対使わない」とか、
          ちょっと前だと「4GBのメモリ空間なんて絶対埋まらない」とか考えられていたわけだから、
          そのうち「昔の人はなんで128ビットのメモリ空間で足りるなんて思ってたんだろう?」とか
          思われてしまうのではないかと。

          親コメント
          • by Anonymous Coward

            そういえば、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 上のメモリと切り替わると目に見えてカウントアップの速度が落ちてました。

                親コメント
              • by Anonymous Coward

                > 8086なプログラムを動かす分には同クロックで比べると386より286の方がちょっぴり速かったんだけど、
                同クロックでは386のほうが286より遅かったです。486になってキャッシュやハードワイヤードロジックを導入しするなど、設計が複雑になり始めたのは遅さをカバーするためと言っても過言ではありません。

              • 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の話無し。

                --
                ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
                親コメント
            • by Anonymous Coward

              >未来なんてわかんないものさ。

              いや、わかる。
              「易きに流れる」ものだ。
              あるいは「安きに流れる」ともいう。

              xxxという商品を安く売り出せるパワー(技術にせよ営業にせよ)が有るかどうか次第、ってことだ。

              そういう意味ではIntelの地球人類に対する「貢献」はすさまじいものがある。
              あの一社がなければ今の世間は全く様相が違っただろう。
              戦後日本の経済成長より余程すごい。

            • by Anonymous Coward
              あー、あったあった。あのときは、286のほうが386より速かったんだよね。
        • ZFSなどの新しい世代のファイルシステムが128bitアドレシングなので、そういった物を扱うには64bitより128bitの方がシンプルで嬉しいと思います。
          親コメント
        • 8bitはキャラクタベースしか扱えなかったのが、16bitで日本語(漢字変換付き)を扱えるようになり、32bitで音声データや動画(やや辛い)、64bitで動画楽勝(まだなっていないけど)、128bitだと立体映像を普通に扱えるようになるのではないかと。
          もちろんディスプレイも3次元データを2次元に投影したものではなく、本当の立体映像を映すものになる。

          これで「うちの嫁は3次元だ」と堂々と言えるようになりますよ。
          ほら、128bit大歓迎な雰囲気がでてきた。
          親コメント
          • by Anonymous Coward

            >「うちの嫁は3次元だ」

            忌避したり裏切り者呼ばわりしたりするだけのこと。

            >8bitはキャラクタベースしか扱えなかったのが、16bitで日本語(漢字変換付き)を扱えるようになり(以下略)

            それらは処理「速度」の問題なんだよね。
            Z80 1GHzを作れば幾つかの問題は解決する。
            主記憶のサイズ制限はたしかに問題だが、SSDみたいに二次が速くなれば色々状況がかわるし。

            言い換えればビット数「ごとき」に限界を支配されるのは、
            いまだに一次RAMという構成から解脱できてないがゆえ。

        •  大量のデータを高速処理するため、オンメモリ型データベースを使用しているところでは「64bitじゃ狭すぎる!」なんて声がそのうち……?
          # そんだけのメモリどうやって実装するんだよ! 二年で容量倍のペースが永遠に続いたとしても、ざっと30bit年たたなきゃ今のメモリモジュールと同じように扱うこと出来ないぞ! 今の段階じゃまだ想像できない技術的ブレークスループリーズ!

          --
          ここは自由の殿堂だ。床につばを吐こうが猫を海賊呼ばわりしようが自由だ。- A.バートラム・チャンドラー 銀河辺境シリーズより
          親コメント
        • by Anonymous Coward

          >必要とするものなんて

          簡単です。
          「無駄遣い」をすればいいのです。

          テレビアニメをHDDに(というかデジタルで)「録画」するなんて、
          無駄遣いもいいところなはずなんだが、
          いちどやったらやめられん…

          実際そんなもんでしょ。
          くっだらない用途を、それでも要望があれば(要望があるのを言い訳とし)やっちゃうのが資本主義。

          実際、くっだらないコンピュータの使い方を誰かが捻り出し、それがもし流行ってしまえば、
          世間の趨勢はそうなる。
          今の32bitだって、Ubuntuのデスクトップがあんなに華麗でなければ※、到底不要なものだったと思うぞ。
          ※WinやMacは言うに及ばず。
          UNIX的に考えて、ビット幅が32「も」常に必要かね?稀にしか必要ないんじゃないの?

        • by Anonymous Coward
          128bit化はSSEではすでに128bit命令があり
          FPUではAMDがPhenomですでにやっているので、
          あとはGPU内臓時にGPU命令が128/256bit命令が入ってくるのに合わせて
          四則演算命令も128bit化するぐらいなのでしょうか。

          用途としては暗号アルゴリズムの処理(ブラウザでSSLとか無線LANで使っているよね)や
          圧縮解凍プログラムの処理(映像系MPEG4とか、音声系IP電話とか、ファイル圧縮とか)
          見えてないだけで需要はあると思います。

にわかな奴ほど語りたがる -- あるハッカー

処理中...