确定处理器的字大小

如何确定CPU的字大小？如果我理解正确一个int应该是一个字对吗？我不确定我是否正确。

那么只要打印sizeof(int)就足以确定我的处理器的字大小了吗？

你对sizeof（int）的假设是不真实的; 看到这个。

由于您必须在编译时知道处理器，OS和编译器，因此可以使用编译器提供的预定义体系结构/ OS /编译器宏来推断字大小。

然而，在更简单和大多数RISC处理器上，字长，总线宽度，寄存器大小和存储器组织通常始终是一个值，对于具有各种大小的浮点寄存器，累加器，总线宽度的更复杂的CISC和DSP架构，情况可能并非如此。，缓存宽度，通用寄存器等

当然，这引出了一个问题，为什么你可能需要知道这一点？通常，您将使用适合应用程序的类型，并信任编译器以提供任何优化。如果您认为优化是您需要的信息，那么您可能最好使用C99’快速’类型。如果您需要优化特定算法，请针对多种类型实施并对其进行分析。

一个int应该是一个字吧？

据我了解，这取决于数据大小模型。有关UNIX系统的说明， 64位和数据大小中立性。例如，Linux 32位是ILP32，而Linux 64位是LP64。除了我相信所有32位Window系统都是ILP32之外，我不确定Window系统和版本之间的区别。

如何确定CPU的字大小？

那要看。你假设哪个版本的C标准。我们在谈论什么平台。这是您尝试制作的编译或运行时间确定。

C头文件可以定义WORD_BIT和/或__WORDSIZE 。

sizeof（int）并不总是CPU的“字”大小。这里最重要的问题是你想知道单词大小的原因….你是否尝试进行某种运行时和CPU特定的优化？

话虽如此，在采用英特尔处理器的Windows上，标称字大小为32位或64位，您可以轻松搞清楚：

这个答案听起来很陈旧，但它对第一顺序是正确的。但是有一些重要的微妙之处。即使现代Intel或AMD处理器上的x86寄存器是64位宽; 您只能（轻松）在32位程序中使用32位宽度 – 即使您可能正在运行64位操作系统。在Linux和OSX上也是如此。

此外，在大多数现代CPU上，数据总线宽度比标准ALU寄存器（EAX，EBX，ECX等）更宽。该总线宽度可以变化，一些系统具有128位，甚至192位宽的总线。

如果您担心性能，那么您还需要了解L1和L2数据缓存的工作方式。请注意，一些现代CPU具有L3缓存。缓存包括一个称为写缓冲区的单元

制作一个多次执行某种整数运算的程序，如SAXPY算法的整数版本。运行它为不同的字大小，从8到64位（即从char到long long ）。

测量每个版本在运行算法时花费的时间。如果有一个特定版本明显少于其他版本，则该版本使用的字大小可能是您计算机的本机字大小。另一方面，如果有多个版本持续或多或少相同的时间，请选择具有更大字长的版本。

请注意，即使使用这种技术，您也可以获得错误数据：使用Turbo C编译并通过DOS在80386处理器上运行的基准测试将报告字大小为16位，因为编译器不使用32位寄存器执行整数aritmetic，但调用执行每个aritmetic操作的32位版本的内部函数。

简而言之：没有好办法。 C数据类型背后的最初想法是int将是最快（本机）整数类型，长期最大等。

然后是来自一个CPU的操作系统，然后移植到其原始字大小不同的不同CPU。为了保持源代码兼容性，一些操作系统打破了该定义并将数据类型保持为旧的大小，并添加了新的非标准数据类型。

也就是说，根据您的实际需要，您可能会在stdint.h找到一些有用的数据类型，或者出于各种目的在特定于编译器或特定于平台的宏中找到它们。

在编译时使用： sizeof(void*)

每个人都可能知道处理器的大小并不重要。

处理器的大小是One CPU Core的Arthematic Logic Unit（ALU）在单个时间点可以处理的日期量。 CPU核心的ALU将随时在累加器寄存器上。因此，以位为单位的CPU大小是以位为单位的累加寄存器的大小。

您可以从处理器的数据表中找到累加器的大小，也可以编写一个小的汇编语言程序。

请注意，累加器寄存器的有效可用大小可以根据操作模式（Thumb和ARM模式）在某些处理器（如ARM）中更改。这意味着处理器的大小也将根据处理器的模式而改变。

在许多体系结构中，常见的是虚拟地址指针大小和整数大小与累加器大小相同。它只是在不同的处理器操作中利用累加器寄存器，但这不是一个硬性规则。