确定我的处理器的字长
如何确定 CPU 的字长？如果我理解正确的话， int 应该是一个单词，对吗？我不确定我是否正确。
那么仅仅打印 sizeof(int) 就足以确定我的处理器的字大小吗？
How do I determine the word size of my CPU? If I understand correct an int should be one word right? I'm not sure if I am correct.
So should just printing sizeof(int) would be enough to determine the word size of my processor?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
您对 sizeof(int) 的假设是不正确的；请参阅此。
由于您必须在编译时了解处理器、操作系统和编译器，因此可以使用预定义的 architecture/OS/compiler 宏来推断字长 由编译器提供。
然而，虽然在更简单的大多数 RISC 处理器上，字大小、总线宽度、寄存器大小和存储器组织通常都是一个值，但对于具有各种浮点寄存器、累加器、总线宽度大小的更复杂的 CISC 和 DSP 架构来说，情况可能并非如此。 、缓存宽度、通用寄存器等。
当然，这引出了一个问题，为什么您可能需要知道这些？通常，您会使用适合应用程序的类型，并信任编译器提供任何优化。如果您认为优化是需要此信息的目的，那么您可能最好使用 C99“快速”类型。如果您需要优化特定算法，请针对多种类型实现它并对其进行分析。
Your assumption about sizeof(int) is untrue; see this.
Since you must know the processor, OS and compiler at compilation time, the word size can be inferred using predefined architecture/OS/compiler macros provided by the compiler.
However while on simpler and most RISC processors, word size, bus width, register size and memory organisation are often consistently one value, this may not be true to more complex CISC and DSP architectures with various sizes for floating point registers, accumulators, bus width, cache width, general purpose registers etc.
Of course it begs the question why you might need to know this? Generally you would use the type appropriate to the application, and trust the compiler to provide any optimisation. If optimisation is what you think you need this information for, then you would probably be better off using the C99 'fast' types. If you need to optimise a specific algorithm, implement it for a number of types and profile it.
据我了解，这取决于数据大小模型。有关 UNIX 系统的说明，请参阅64 位和数据大小中立性。例如Linux 32位是ILP32，Linux 64位是LP64。我不确定 Window 系统和版本之间的差异，但我相信所有 32 位 Window 系统都是 ILP32。
这要看情况。您假设使用哪个版本的 C 标准。我们在谈论什么平台。这是您想要做出的编译时还是运行时决定。
C头文件
WORD_BIT和/或__WORDSIZE。As I understand it, that depends on the data size model. For an explanation for UNIX Systems, 64-bit and Data Size Neutrality. For example Linux 32-bit is ILP32, and Linux 64-bit is LP64. I am not sure about the difference across Window systems and versions, other than I believe all 32-bit Window systems are ILP32.
That depends. Which version of C standard are you assuming. What platforms are we talking. Is this a compile or run time determination you're trying to make.
The C header file
<limits.h>may definesWORD_BITand/or__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 缓存。高速缓存包括一个称为写入缓冲区的单元
sizeof(int) is not always the "word" size of your CPU. The most important question here is why you want to know the word size.... are you trying to do some kind of run-time and CPU specific optimization?
That being said, on Windows with Intel processors, the nominal word size will be either 32 or 64 bits and you can easily figure this out:
This answer sounds trite, but its true to the first order. But there are some important subtleties. Even though the x86 registers on a modern Intel or AMD processor are 64-bits wide; you can only (easily) use their 32-bit widths in 32-bit programs - even though you may be running a 64-bit operating system. This will be true on Linux and OSX as well.
Moreover, on most modern CPU's the data bus width is wider than the standard ALU registers (EAX, EBX, ECX, etc). This bus width can vary, some systems have 128 bit, or even 192 bit wide busses.
If you are concerned about performance, then you also need to understand how the L1 and L2 data caches work. Note that some modern CPU's have an L3 cache. Caches including a unit called the Write Buffer
编写一个多次执行某种整数运算的程序，例如 SAXPY 算法的整数版本。针对不同的字长运行它，从 8 位到 64 位（即从
char到long long）。测量每个版本运行算法所花费的时间。如果某个特定版本的持续时间明显短于其他版本，则该版本使用的字长可能是计算机的本机字长。另一方面，如果有多个版本的持续时间大致相同，则选择字长较大的版本。
请注意，即使使用此技术，您也可能获得错误数据：使用 Turbo C 编译并通过 DOS 在 80386 处理器上运行的基准测试将报告字大小为 16 位，只是因为编译器不使用 32 位寄存器执行整数算术运算，但调用执行每个算术运算的 32 位版本的内部函数。
Make a program that does some kind of integer operation many times, like an integer version of the SAXPY algorithm. Run it for different word sizes, from 8 to 64 bits (i.e. from
chartolong long).Measure the time each version spends while running the algorithm. If there is one specific version that lasts noticeably less than the others, the word size used for that version is probably the native word size of your computer. On the other way, if there are several versions that last more or less the same time, pick up the one which has the greater word size.
Note that even with this technique you can get false data: your benchmark, compiled using Turbo C and running on a 80386 processor through DOS will report that the word size is 16 bits, just because the compiler doesn't use the 32-bit registers to perform integer aritmetic, but calls to internal functions that do the 32-bit version of each aritmetic operation.
“此外，C 类型 long 的大小等于字长，而 int 类型的大小有时小于字长。例如，Alpha 有64 位字大小。因此，寄存器、指针和 long 类型的长度都是 64 位。”
来源：http://books.msspace.net/mirrorbooks/kerneldevelopment/0672327201/ch19lev1sec2.html
记住这一点，可以执行以下程序来找出您正在使用的机器的字长 -
"Additionally, the size of the C type long is equal to the word size, whereas the size of the int type is sometimes less than that of the word size. For example, the Alpha has a 64-bit word size. Consequently, registers, pointers, and the long type are 64 bits in length."
source: http://books.msspace.net/mirrorbooks/kerneldevelopment/0672327201/ch19lev1sec2.html
Keeping this in mind, the following program can be executed to find out the word size of the machine you're working on-
简而言之：没有什么好办法。 C 数据类型背后的最初想法是 int 是最快的（本机）整数类型，long 是最大的整数类型，等等。
然后出现了源自一个 CPU 的操作系统，然后移植到本机字大小不同的不同 CPU。为了保持源代码兼容性，一些操作系统打破了该定义，将数据类型保留为旧大小，并添加了新的非标准数据类型。
也就是说，根据您的实际需要，您可能会在
stdint.h中找到一些有用的数据类型，或者用于各种目的的特定于编译器或特定于平台的宏。In short: There's no good way. The original idea behind the C data types was that int would be the fastest (native) integer type, long the biggest etc.
Then came operating systems that originated on one CPU and were then ported to different CPUs whose native word size was different. To maintain source code compatibility, some of the OSes broke with that definition and kept the data types at their old sizes, and added new, non-standard ones.
That said, depending on what you actually need, you might find some useful data types in
stdint.h, or compiler-specific or platform-specific macros for various purposes.在编译时使用：
sizeof(void*)To use at compile time:
sizeof(void*)知道处理器大小的原因并不重要。
处理器的大小是指一个CPU核心的算术逻辑单元（ALU）在单个时间点可以处理的数据量。 CPU 核心的 ALU 将随时保存在累加器寄存器中。因此，CPU 的大小（以位为单位）就是累加器寄存器的大小（以位为单位）。
您可以从处理器的数据表或通过编写一个小型汇编语言程序来找到累加器的大小。
请注意，在某些处理器（如 ARM）中，累加器寄存器的有效可用大小可能会根据操作模式（Thumb 和 ARM 模式）而变化。这意味着处理器的大小也会根据该处理器的模式而变化。
在许多体系结构中，虚拟地址指针大小和整数大小与累加器大小相同是常见的。这只是为了在不同的处理器操作中利用累加器寄存器，但这不是硬性规则。
What every may be the reason for knowing the size of the processor it don't matter.
The size of the processor is the amount of date that Arthematic Logic Unit(ALU) of One CPU Core can work on at a single point of time. A CPU Cores's ALU will on Accumulator Register at any time. So, The size of a CPU in bits is the the size of Accumulator Register in bits.
You can find the size of the accumulator from the data sheet of the processor or by writing a small assembly language program.
Note that the effective usable size of Accumulator Register can change in some processors (like ARM) based on mode of operations (Thumb and ARM modes). That means the size of the processor will also change based on the mode for that processors.
It common in many architectures to have virtual address pointer size and integer size same as accumulator size. It is only to take advantage of Accumulator Register in different processor operations but it is not a hard rule.
许多人将内存视为字节数组。但CPU对此却有不同的看法。这是关于内存粒度的。根据架构的不同，内存粒度可能有 2、4、8、16 甚至 32 字节。内存粒度和地址对齐对软件的性能、稳定性和正确性有很大影响。考虑 4 字节的粒度和以 4 字节读取的未对齐内存访问。在这种情况下，每次读取（如果地址增加一个字节，则 75%）需要另外两条读取指令加上两次移位操作，最后是一条按位指令以获得最终结果，这是性能杀手。进一步的原子操作可能会受到影响，因为它们必须是不可分割的。其他副作用包括缓存、同步协议、CPU 内部总线流量、CPU 写入缓冲区以及您猜猜还有什么。可以在循环缓冲区上运行实际测试，看看结果有何不同。不同厂家的CPU，根据型号的不同，有不同的寄存器，用于通用操作和特定操作。例如，现代 CPU 具有 128 位寄存器的扩展。因此，字长不仅与操作类型有关，还与内存粒度有关。字长和地址对齐是必须要注意的问题。市场上有一些 CPU 不关心地址对齐，如果提供的话则简单地忽略它。猜猜会发生什么？
Many thinks of memory as an array of bytes. But CPU has another view of it. Which is about memory granularity. Depending on architecture, there would be 2, 4, 8, 16 or even 32 bytes memory granularity. Memory granularity and address alignment have great impact on performance, stability and correctness of software. Consider a granularity of 4 bytes and an unaligned memory access to read in 4 bytes. In this case every read, 75% if address is increasing by one byte, takes two more read instructions plus two shift operations and finally a bitwise instruction for final result which is performance killer. Further atomic operations could be affected as they must be indivisible. Other side effects would be caches, synchronization protocols, cpu internal bus traffic, cpu write buffer and you guess what else. A practical test could be run on a circular buffer to see how the results could be different. CPUs from different manufacturers, based on model, have different registers which will be used in general and specific operations. For example modern CPUs have extensions with 128 bits registers. So, the word size is not only about type of operation but memory granularity. Word size and address alignment are beasts which must be taken care about. There are some CPUs in market which does not take care of address alignment and simply ignore it if provided. And guess what happens?
正如其他人指出的那样，您对计算这个值有何兴趣？有很多变数。
sizeof(int) != sizeof(word)。字节、字、双字等的大小自创建以来从未改变过，至少是为了 Windows API 世界中的 API 兼容性。即使处理器字大小是指令可以操作的自然大小。例如，在msvc/cpp/c#中，sizeof(int)是四个字节。即使在 64 位编译模式下也是如此。 Msvc/cpp 有 __int64，c# 有 Int64/UInt64（不符合 CLS）ValueType。 win32 API 中还有 WORD DWORD 和 QWORD 的类型定义，分别从未改变过两个字节、四个字节和八个字节。以及 Win32 上的 UINT/INT_PTR 和 c# 上的 UIntPtr/IntPtr 保证足够大以分别表示内存地址和引用类型。 AFAIK，如果 arch 仍然存在，我可能是错的，我认为没有人需要处理，近/远指针也不再存在，所以如果你使用 c/cpp/c#，sizeof(void*)和 Unsafe.SizeOf{IntPtr}() 足以确定我认为以兼容的跨平台方式的最大“单词”大小，如果有人可以纠正它，请这样做！此外，c/cpp 中内在类型的大小在大小定义上也很模糊。
C 数据类型大小 - 维基百科
As others have pointed out, how are you interested in calculating this value? There are a lot of variables.
sizeof(int) != sizeof(word). the size of byte, word, double word, etc have never changed since their creation for the sake of API compatibility in the windows api world at least. Even though a processor word size is the natural size an instruction can operate on. For example, in msvc/cpp/c#, sizeof(int) is four bytes. Even in 64bit compilation mode. Msvc/cpp has __int64 and c# has Int64/UInt64(non CLS compliant) ValueType's. There are also type definitions for WORD DWORD and QWORD in the win32 API that have never changed from two bytes, four bytes, and eight bytes respectively. As well as UINT/INT_PTR on Win32 and UIntPtr/IntPtr on c# that are guranteed to be big enough to represent a memory address and a reference type respectively. AFAIK, and I could be wrong if arch's still exist, I don't think anyone has to deal with, nor do, near/far pointers exist anymore, so if you're on c/cpp/c#, sizeof(void*) and Unsafe.SizeOf{IntPtr}() would be enough to determine your maximum "word" size I would think in a compliant cross-platform way, and if anyone can correct that, please do so! Also, sizes of intrinsic types in c/cpp are vague in size definition.
C data type sizes - Wikipedia