CPU のワード サイズはどのように決定すればよいですか? 私が正しいことを理解していればint
、1つの単語である必要がありますよね? 私が正しいかどうかはわかりません。
では、プロセッサのワードサイズを決定するには、印刷するだけsizeof(int)
で十分でしょうか?
sizeof(int) に関するあなたの仮定は正しくありません。これを参照してください。
コンパイル時にプロセッサ、OS、およびコンパイラを知る必要があるため、コンパイラによって提供される定義済みのアーキテクチャ/OS/コンパイラ マクロを使用してワード サイズを推測できます。
ただし、より単純なほとんどの RISC プロセッサでは、ワード サイズ、バス幅、レジスタ サイズ、およびメモリ構成は多くの場合一貫して 1 つの値ですが、これは浮動小数点レジスタ、アキュムレータ、バス幅のさまざまなサイズを持つより複雑な CISC および DSP アーキテクチャには当てはまらない場合があります。 、キャッシュ幅、汎用レジスタなど。
もちろん、なぜこれを知る必要があるのかという疑問が生じます。一般に、アプリケーションに適した型を使用し、コンパイラが最適化を提供することを信頼します。最適化のためにこの情報が必要だと考える場合は、おそらくC99 の「高速」タイプを使用する方がよいでしょう。特定のアルゴリズムを最適化する必要がある場合は、それをいくつかのタイプに実装し、プロファイリングします。
int は 1 語ですよね?
私が理解しているように、それはデータサイズモデルに依存します。UNIX システム、 64 ビット、および Data Size Neutralityの説明については、. たとえば、Linux 32 ビットは ILP32、Linux 64 ビットは LP64 です。すべての 32 ビット Windows システムが ILP32 であると信じていることを除けば、Windows システムとバージョン間の違いについてはよくわかりません。
CPU のワード サイズはどのように決定すればよいですか?
場合によります。C標準のどのバージョンを想定していますか。私たちが話しているプラットフォームは何ですか。これは、あなたが行おうとしているコンパイル時または実行時の決定ですか。
C ヘッダー ファイルは、および/または<limits.h>
を定義する場合があります。WORD_BIT
__WORDSIZE
sizeof(int) は、常に CPU の「ワード」サイズとは限りません。ここで最も重要な質問は、なぜワードサイズを知りたいのかということです.... 何らかのランタイムおよび CPU 固有の最適化を行おうとしているのですか?
そうは言っても、Intel プロセッサを搭載した Windows では、公称ワード サイズは 32 ビットまたは 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
) のさまざまなワード サイズで実行します。
アルゴリズムの実行中に各バージョンが費やす時間を測定します。他のバージョンよりも著しく寿命が短い特定のバージョンがある場合、そのバージョンに使用されるワード サイズは、おそらくコンピューターのネイティブ ワード サイズです。反対に、多かれ少なかれ同時に存続する複数のバージョンがある場合は、単語サイズが大きいバージョンを選択します。
この手法を使用しても、誤ったデータが得られる可能性があることに注意してください。Turbo C を使用してコンパイルされ、DOS を介して 80386 プロセッサで実行されているベンチマークでは、コンパイラが 32 ビット レジスタを使用しないという理由だけで、ワード サイズが 16 ビットであると報告されます。整数の算術演算を実行しますが、各算術演算の 32 ビット バージョンを実行する内部関数を呼び出します。
要するに:良い方法はありません。C データ型の背後にある元のアイデアは、int が最速 (ネイティブ) の整数型であり、long が最大などでした。
その後、1 つの CPU で開発されたオペレーティング システムが、ネイティブ ワード サイズが異なる別の CPU に移植されました。ソース コードの互換性を維持するために、一部の OS はその定義を破り、データ型を古いサイズのままにし、新しい非標準型を追加しました。
とは言っても、実際に必要なものに応じて、stdint.h
さまざまな目的で 、またはコンパイラ固有またはプラットフォーム固有のマクロでいくつかの有用なデータ型を見つけることができます。
コンパイル時に使用するには:sizeof(void*)
他の人が指摘したように、この値を計算することにどのように関心がありますか? 多くの変数があります。
sizeof(int) != sizeof(単語). バイト、ワード、ダブルワードなどのサイズは、少なくとも Windows API の世界での API 互換性のために作成されて以来、変更されていません。プロセッサのワードサイズは、命令が操作できる自然なサイズですが。たとえば、msvc/cpp/c# では、sizeof(int) は 4 バイトです。64 ビットのコンパイル モードでも。Msvc/cpp には __int64 があり、c# には Int64/UInt64 (非 CLS 準拠) の ValueType があります。win32 API には、それぞれ 2 バイト、4 バイト、8 バイトから変更されていない WORD DWORD および QWORD の型定義もあります。Win32 の UINT/INT_PTR と c# の UIntPtr/IntPtr と同様に、それぞれメモリ アドレスと参照型を表すのに十分な大きさであることが保証されています。私の知る限り、アーチがまだ存在する場合、私は間違っている可能性があります。誰も対処する必要はないと思います。Near/Far ポインターはもう存在しないため、c/cpp/c# を使用している場合は、sizeof(void*) と Unsafe.SizeOf{IntPtr}() で最大の「単語」サイズを判断できます。クロスプラットフォームの方法で、誰かがそれを修正できる場合は、そうしてください! また、c/cpp の組み込み型のサイズは、サイズの定義が曖昧です。