プロセッサのワードサイズを確認する
CPUのワードサイズを確認するにはどうすればよいですか？私が正しいと理解している場合、intは1つの単語である必要がありますか？私が正しいかどうかはわかりません。
それで、単にsizeof(int)を出力するだけで、私のプロセッサのWordサイズを決定できますか？
Sizeof（int）に関する仮定は正しくありません。 this を参照してください。
コンパイル時にプロセッサ、OS、およびコンパイラを知っている必要があるため、コンパイラによって提供される事前定義された architecture/OS/compiler macros を使用してワードサイズを推測できます。
ただし、より単純でほとんどのRISCプロセッサでは、ワードサイズ、バス幅、レジスタサイズ、およびメモリ構成が一貫して1つの値であることがよくありますが、これは、浮動小数点レジスタ、アキュムレータ、バス幅にさまざまなサイズのより複雑なCISCおよびDSPアーキテクチャには当てはまらない場合があります、キャッシュ幅、汎用レジスタなど。
もちろん、なぜこれを知っておく必要があるのでしょうか。一般に、アプリケーションに適したタイプを使用し、コンパイラーを信頼して最適化を提供します。この情報が必要であると考える最適化である場合は、おそらく C99 'fast' types を使用する方が良いでしょう。特定のアルゴリズムを最適化する必要がある場合は、それをいくつかのタイプに実装し、プロファイルします。
intは1つのWordである必要がありますか？
私が理解しているように、それはデータサイズモデルに依存します。 UNIXシステムの説明については、 64ビットおよびデータサイズの中立性 です。たとえば、Linux 32ビットはILP32、Linux 64ビットはLP64です。すべての32ビットウィンドウシステムがILP32であると思う以外は、ウィンドウシステムとバージョンの違いについてはわかりません。
CPUのワードサイズを確認するにはどうすればよいですか？
場合によります。想定しているC標準のバージョンはどれですか。私たちが話しているプラットフォームは何ですか。これは、作成しようとしているコンパイルまたはランタイムの決定ですか？.
Cヘッダーファイル<limits.h>はWord_BITおよび/または__WORDSIZE。
sizeof（int）は、CPUの「ワード」サイズであるとは限りません。ここで最も重要な質問はwhy Wordのサイズを知りたい...何かをしようとしていますか？実行時およびCPU固有の最適化の？
そうは言っても、Intelプロセッサを搭載したWindowsでは、名目上のWordサイズは32ビットまたは64ビットのいずれかであり、これは簡単に理解できます。
- プログラムが32ビット用にコンパイルされている場合、公称Wordサイズは32ビットです。
- 64ビットプログラムをコンパイルした場合、Wordの公称サイズは64ビットです。
この答えは控えめに聞こえますが、最初の注文に当てはまります。しかし、いくつかの重要な微妙な点があります。最新のIntelまたはAMDプロセッサーのx86レジスターは64ビット幅ですが、 64ビットオペレーティングシステムを実行している場合でも、32ビットプログラムでは32ビット幅を（簡単に）しか使用できません。これはLinuxとOSXにも当てはまります。
さらに、ほとんどの最近のCPUでは、データバス幅は標準のALUレジスタ（EAX、EBX、ECXなど）よりも広くなっています。このバス幅は変動する可能性があり、一部のシステムでは128ビット、または192ビット幅のバスさえ備えています。
パフォーマンスが心配な場合は、L1およびL2データキャッシュのしくみについても理解する必要があります。最近のCPUにはL3キャッシュを備えているものがあることに注意してください。書き込みバッファと呼ばれるユニットを含むキャッシュ
SAXPYアルゴリズムの整数バージョンのように、ある種の整数演算を何度も行うプログラムを作成します。 8から64ビット（つまり、charからlong long）までのさまざまなWordサイズで実行します。
アルゴリズムの実行中に各バージョンが費やす時間を測定します。他のバージョンよりも著しく持続する特定のバージョンが1つある場合、そのバージョンに使用されるWordサイズは、コンピューターのネイティブのWordサイズである可能性があります。逆に、ほぼ同じ時間続くバージョンが複数ある場合は、Wordサイズの大きいバージョンを選択します。
この手法を使用しても誤ったデータを取得できることに注意してください。TurboCを使用してコンパイルされ、DOS経由で80386プロセッサで実行されているベンチマークは、コンパイラが32ビットレジスタを使用していないため、Wordサイズが16ビットであると報告します。整数演算を実行しますが、各演算の32ビットバージョンを実行する内部関数を呼び出します。
つまり、良い方法はありません。 Cデータ型の背後にある元のアイデアは、intが最も高速な（ネイティブ）整数型で、longが最大であることなどです。
その後、1つのCPUで発生し、ネイティブのWordサイズが異なるさまざまなCPUに移植されたオペレーティングシステムが登場しました。ソースコードの互換性を維持するために、一部のOSはその定義に違反し、データ型を古いサイズのままにし、新しい非標準のデータ型を追加しました。
そうは言っても、実際に何が必要かによっては、stdint.h、またはさまざまな目的のためのコンパイラ固有またはプラットフォーム固有のマクロにいくつかの有用なデータ型が見つかる場合があります。
プロセッサのサイズを知る必要がない理由は何でしょうか。
プロセッサのサイズは、1つのCPUコアの算術論理演算ユニット（ALU）が単一の時点で動作できる日付の量です。 CPUコアのALUはいつでもアキュムレータレジスタをオンにします。したがって、ビット単位のCPUのサイズは、ビット単位のアキュムレータレジスタのサイズです。
アキュムレータのサイズは、プロセッサのデータシートから、または小さなアセンブリ言語プログラムを記述することで確認できます。
一部のプロセッサ（ARMなど）では、操作モード（ThumbおよびARM mode）に基づいて、有効なアキュムレータレジスタのサイズが変わる可能性があることに注意してください。つまり、プロセッサのサイズもそのプロセッサのモードで。
多くのアーキテクチャでは、仮想アドレスポインタサイズと整数サイズがアキュムレータサイズと同じになるのが一般的です。さまざまなプロセッサ操作でアキュムレータレジスタを利用するだけですが、それは難しい規則ではありません。
コンパイル時に使用するには：sizeof(void*)
多くの人はメモリをバイトの配列と考えています。しかし、CPUには別の見方があります。これは、メモリの粒度に関するものです。アーキテクチャに応じて、2、4、8、16、または32バイトのメモリの細分性があります。メモリの細分性とアドレス調整は、ソフトウェアのパフォーマンス、安定性、正確性に大きな影響を与えます。 4バイトの細分性と、4バイトで読み取るための非境界整列メモリアクセスを検討してください。この場合、すべての読み取り（アドレスが1バイト増加している場合は75％）は、さらに2つの読み取り命令と2つのシフト操作、そして最終的にはパフォーマンスキラーである最終結果のビットごとの命令を必要とします。さらに不可分な操作は不可分でなければならないため、影響を受ける可能性があります。その他の副作用としては、キャッシュ、同期プロトコル、CPU内部バストラフィック、CPU書き込みバッファなどがあります。実際のテストを循環バッファで実行して、結果がどのように異なるかを確認できます。モデルに基づいて、さまざまなメーカーのCPUには、一般的な操作と特定の操作で使用されるさまざまなレジスタがあります。たとえば、最近のCPUには128ビットのレジスタを持つ拡張機能があります。したがって、ワードサイズは、操作のタイプだけでなく、メモリの粒度にも関係します。ワードサイズとアドレスの配置は、注意が必要な獣です。市場には、アドレス調整を処理せず、提供された場合に単にそれを無視するCPUがあります。そして何が起こると思いますか？