Cli*_*ord 21
你对sizeof(int)的假设是不真实的; 看到这个.
由于您必须在编译时知道处理器,OS和编译器,因此可以使用编译器提供的预定义体系结构/ OS /编译器宏来推断字大小.
然而,在更简单和大多数RISC处理器上,字长,总线宽度,寄存器大小和存储器组织通常始终是一个值,对于具有各种大小的浮点寄存器,累加器,总线宽度的更复杂的CISC和DSP架构,这可能不是这样. ,缓存宽度,通用寄存器等
当然,这引出了一个问题,为什么你可能需要知道这个？通常,您将使用适合应用程序的类型,并信任编译器以提供任何优化.如果您认为优化是您需要的信息,那么您可能最好使用C99'快速'类型.如果您需要优化特定算法,请针对多种类型实施并对其进行分析.
一个int应该是一个字吧？
据我了解,这取决于数据大小模型.有关UNIX系统的说明,64位和数据大小中立性.例如,Linux 32位是ILP32,而Linux 64位是LP64.我不确定Window系统和版本之间的区别,除了我相信所有32位Window系统都是ILP32.
如何确定CPU的字大小？
那要看.你假设哪个版本的C标准.我们在谈论什么平台.这是您尝试制作的编译或运行时间确定.
C头文件<limits.h>可以定义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缓存.缓存包括一个称为写缓冲区的单元
| 归档时间： |
|
| 查看次数： |
35014 次 |
| 最近记录： |