- ベストアンサー
32bitと64bitに関する基礎的な事柄
- 32bitと64bitとは、CPUが一度に読み込むことのできるデータの量を表します。
- OSは、CPUが32bitか64bitかを認識しており、それに応じた処理を選択します。
- アプリケーションは、OSに作業の指示を出すだけで、PCのCPUについては気にする必要はありません。
- みんなの回答 (7)
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
>OSは、当然、CPUが32bitであるのか、64bitであるのかを、きっと認識していて、32bitCPUに対しての処理と、64bitCPUに対する処置を選択していると考えます。 これは微妙に違います。 OSはもちろんCPUが32bitか64bitかを判断出来ますが、32bitのCPUなら32bitのOSしか動きません。 また、64bitのCPUでは32bitのOSは動きますが、これは64bitCPUが32bitモードで動作しているから32bitのOSを起動出来るのです。CPUが64bitモードでは、32bitOSは起動出来ません。 ちなみに64bitOSで32bitアプリが動くのは、CPUの32bit部分を使っているという訳では無く、64bitOS上で32bit環境をエミュレートしているからです。 Windowsではカーネル(OSの基本部分)の上にWin32(名前の通り32bit)もしくはWin64(同64bit)というAPIがあり、その上でアプリが動いているのですが、Win64上ではWin32用アプリ(要は32bitアプリ)は動きません。 64bitのWindowsでは、WOW64というWin64上で動くWin32エミュレータが用意されており、この上で32bitアプリが動いています。 (細かい話ですが、上記の関係で64bitOSで動いている32bitアプリは64bitのDLLの呼び出しが行えません。WOW64からWin64の呼び出しはセキュリティ上の問題もあって出来なくなっています。このため一部の32bitアプリでは64bitOSで使うと問題が出たりします) >アプリケーションレベルでは、OSに作業の指示を出すのであって、アプリケーションは、 >PCがどんなCPUをつかっているのか、気にする必用はないのではないかと考えます。 ユーザが本当に「単に使う人」ならその認識で合っていますが、もう少し上を目指すなら間違っているとも言えるでしょう。 CPUは、製品によって持っている命令が違います。 高速な計算が要求されるアプリなどではCPUの種類をしっかり認識して、そのCPUに合った命令を使ったりします。 現状、マトモに売っているCPUは全て64bitですが、OSは64bitと32bitが入り乱れています。先程書いたWOW64環境からWin64が読み出せない問題など、OSに任していてはどうにもならない問題が数多くあるため、開発者はOSなどの環境に常に気を付けなければなりません。
その他の回答 (6)
- RandenSai
- ベストアンサー率54% (305/561)
> 32bit,64bitとは、CPUが一度に読み込むことの出来るデータの量を言っているのだと思います。 大体それで合っています。細かい話はNo.4回答者さんから出ているようなことになります。平たく言えば、CPUが普通に取り扱えるデータ幅が32bitなのか64bitなのかを指しているのだと言うわけです。 一般的に、32bitよりも64bitのCPUの方が大きなデータを高速に扱いやすいため、もしアプリが32/64を選べるんだったら、64を選んだ方が高速化しやすく、大容量のデータが扱える。ただしOfficeのような長い歴史のあるソフトで、過去のバージョンと互換性問題を生ずるといった場合もあるので、常に64が良いとは限りませんが、一般的にはそういう形です。普通のユーザーはその程度の認識でいれば充分かと。 メモリの話も出ていますが、32bitCPUのメモリ容量が4GBなのはメモリバス幅も32bitだからですが、実はこれは決まりじゃありません。32bitCPUのメモリバス幅は32bit以外であっても規格には反しないし、64bitもまた然り。そもそもそれを定義する規格はないと言うべきかも?一番普及したものが32bit幅だったからにすぎず、みんなそれに合わせただけであって。 事実、世の中に出回っている64bitCPUの大半を占めるx64仕様のものは、メモリバス幅が64bitではなく48bitです。時代を遡り、インテル初の16bitCPUであるi8086はメモリバス幅20bitだが、同時期のモトローラ製MC68000のそれは24bit。同じ16bitCPUなのにメモリバス幅が違う。もっと遡って8bitCPUまで行くとメモリバス幅は16bitが主流でした。つまり、xxbitCPUというbit数とメモリバス幅は一致しないことの方が多いものです。たまたま32bitでは一致していたけれど、それは本当にたまたまですよ。
お礼
ありがとうございます。 少し、わかってきました。
- drum_KT
- ベストアンサー率43% (1108/2554)
この場合の32bit/64bitというのは、一度に読み込むデータの量が32bit/64bitと言っているわけではなくて、メモリーのアドレスを何bitで表現しているかを表しています。 そのため、32bit OSの場合、搭載できるメモリーがトータルで最大4GB(2の32乗)に制限されます。 ところが、アプリケーションのレベルでさえ、4GB以上のメモリーを扱いたいケースというのが徐々に増えてきて、そういった場合には、64bit CPU上の64bit OSで64bitアプリケーションを使う必要が出てきます。 具体例として、最初に64bit対応したアプリケーションは、大量のデータを高速に扱う必要があるデータベースソフトです。このようなアプリケーションは、64bitのアドレス空間が使えることを前提に、4GBを大きく超えるデータをメモリー上に読み込んで処理することで、高速処理を実現しようとします。
お礼
ありがとうございます。 少し、わかってきました。
- bardfish
- ベストアンサー率28% (5029/17766)
単なるエンドユーザーならOSとソフトの対応状況を確認するだけで問題ありません。 でも、プログラムを作るというのなら別。 他の人も回答していますが、プログラミング言語にはCPUに依存したコーディングが可能なものもあります。 実行時の効率を最大限に発揮したいならCPUに特化したコーディングを行ったほうが良い。C++でもいいけどアセンブラで作成したものにかなう高級言語はまず無い。 実際、DLLなどを作成するときはC++ソースの中にアセンブラでコードを記述することもある。 32ビットとか64ビットというのはデータ幅を表すときに使う。 ※例外もある データ幅に合わせてCPU内部にはレジスタと呼ばれるCPU専属メモリがあるのだが、この取り扱い方でOSを含むソフトで対応/非対応の差が出てくる。 大は小を兼ねることができるが、その逆はできない。 64ビット環境で32ビットソフトは動かせるが、32ビット環境で64ビットソフトは動かせない。 レジスタを例に上げると、ソフトからCPUにデータの受け渡しに使用するバケツの大きさがレジスタとしましょう。 32ビットレジスタは小さいバケツ。 64ビットレジスタは大きいバケツ。 大きいバケツに小さいデータを入れることはできるが、小さいバケツに大きいデータを入れることはできない。 それを実行しようとすると、別の用途で使用しているバケツにデータが溢れるなどして暴走しかねない。 そういうことを回避するためにOSでチェックする。 OSが低機能だった頃はそういったたぐいの単純ミスでよく暴走させてましたけど(笑) プログラム経験者ならここまででピンとくるかもしれませんが、APIのパラメータにも32/64ビットの違いがあります。 64ビットOSだと同じ結果が得られるAPIでも32ビット用、64ビット用と用意されていることもあります。
お礼
ありがとうございます。 少し、わかってきました。
- mk48a
- ベストアンサー率56% (1133/2007)
JAVAやC#などでプログラムされたものは64bit、32bitどちらでも動くようにできますが、C++などでプログラムされたものは32bitと64bit用は分けています。 32bit用は64bitOSでもたいてい動きますが、64bit用は32bitOSでは動きません。 また、共通ライブラリ(DLLなど)を使用する場合はアプリケーションが64bitで動作している場合は64bitのもの、32bitで動作している場合は32bitのものしか使用できません。 なので、プログラムの際に32bitOSか64bitOSか両方で使用するのかを考慮してプログラムする必要があります。 アプリケーションのプラグインなんかもDLLだったりする場合があります。
お礼
ありがとうございます。 少し、わかってきました。
32bitOSでは64bit方式のアプリは動かせませんので、そこだけ気を付ければ大丈夫です。 他の組み合わせは問題ありません。
お礼
ありがとうございます。 少し、わかってきました。
- PXU10652
- ベストアンサー率38% (777/1993)
「アプリケーションレベルでは、OSに作業の指示を出すのであって、アプリケーションは、 PCがどんなCPUをつかっているのか、気にする必用はないのではないかと考えます。」 その通りですよ。CPUは現在では64bitしかありませんので、OSが32bitで動作していたり、64bitOS上で32bitアプリが動く仕掛けが用意されています。
お礼
ありがとうございます。 少し、わかってきました。
補足
色々ありがとうございます。 かなり、理解できました。 現実問題として、自作パソコンを計画しています。 会社では、仕事にExcelのVBAを使って、業務の効率化を図っています。 家のパソコンでも、思いついたアイデアを試したり、デバッグ等をしています。 従って、会社と家でのVBAソースの互換性が必要です。 今まででも、WindowsXP上でのExcel2003とExcel2010でのVBAの互換性に苦労しました。 Win32を呼び出したりもしています。 会社のPCも順次新しくなっていきます。自宅のPCも新しくしようと考えています。 OSの選択(32bit/64bit)をしなければならない、というところで、足踏みをしていたのです。 結局、OSが会社と自宅とで、異なっていると、これは、どうしようもないということがわかりました。 会社では、従来のVBAソースが動かないでは、本当に仕事になりませんから、 64bitOS上, WOW64で、x86をエミュレートして32bit版Excelを選択することになると考えます。 ただ、まだ、自信がないのは、 >64bitOSで動いている32bitアプリは64bitのDLLの呼び出しが行えません 32bitアプリが、32bitのAPI、DLLしか使っていない限りは、全く問題がない、と理解して正しいでしょうか? コメントをいただければ、幸いです。