LP64、LLP64 和 IL32 转变
在 80 年代从 16 位到 32 位的过渡期间，int 要么是 16 位，要么是 32 位。使用当前的 64 位转换命名法，我知道 ILP32 和 LP32 机器的分布相当均匀。当时我相信，对于任何给定的体系结构，int 始终遵循寄存器或指针宽度，而 long 将保持 32 位。
快进 25 年，我看到 LP64 相当主流，但直到我遇到 64 位平台 [我在 2007 年发现桌面 Linux :)]，我一直期望 IP64 成为下一个合乎逻辑的步骤。
- 这是 (LP64) 64 位的预期演变吗？
char≤short≤int≤long关系如何适应这种将整数类型固定为新兴方案我们留下的每个平台？- 这些转换方案与（您选择的
{l,u}case）WORD/DWORD在各种平台上的使用有何关系？ - Windows 的某些区域仍然包含 16 位的
INT形式。 Windows 会摆脱 LLP64 还是已经太晚了？ - 为什么这次选择将
int留在后面，而不是在 32 位过渡期间？
During the transition from 16 to 32 bit in the 80s, int was either 16 or 32 bit. Using the current 64 bit transition nomenclature, I understand there was a pretty even spread of ILP32 and LP32 machines. At the time I believe it was understood that int would always follow the register or pointer width for any given architecture and that long would remain 32 bit.
Fast forward 25 years, I see that LP64 is pretty mainstream, but until I encountered 64 bit platforms [my discovery of desktop Linux in 2007 :)], I always expected IP64 to be the next logical step.
- Was this (LP64) the expected evolution for 64bit?
- How does the
char≤short≤int≤longrelationship fit into this emerging scheme of fixing an integer type to each platform we leave behind? - How do these transition schemes relate to the use of (your choice of
{l,u}case)WORD/DWORDon various platforms? - Some areas of Windows still contain
INTforms that are 16bit. Will Windows grow out of LLP64 or is it too late? - Why was
intchosen to be left behind this time, as opposed to during the 32bit transition?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我的看法是 Windows 在整个 x64 过渡中是一个奇怪的东西。但抛开这一点，C 或 C++ 从未将整型类型定义为固定长度。我发现整个
int/long/pointer事情很容易理解，如果你这样看的话：int：大部分为 32 位长（Linux、Mac 和 Windows）long：Mac 和 Linux 上为 64 位，Windows 上为 32long long：Mac、Linux 上为 64 位Windows x64u)intptr_t：指针的精确长度（32 位系统上为 32，64 位系统上为 64）WORD和DWORD很难看，应该避免。如果 API 强制您使用它们，请在处理……好吧，指针时将DWORD替换为DWORD_PTR。恕我直言，首先使用 (D)WORD从来都是不正确的。我认为 Windows 永远不会改变其决定。已经太麻烦了。
为什么
int被抛在后面？为什么金星以相反的方向自转？第一个问题的答案可以在这里找到（我相信），第二个问题有点复杂;)How I see it is that Windows is an oddball in the whole x64 transition. But putting that aside, C or C++ never defined the integral types to be fixed-length. I find the whole
int/long/pointerthing quite understandable, if you look at it this way:int: mostly 32 bits long (Linux, Mac and Windows)long: 64 bits on Mac and Linux, 32 on Windowslong long: 64-bit on Mac, Linux, and Windows x64u)intptr_t: exact length of pointer (32 on 32-bit, 64 on 64-bit systems)WORDandDWORDare ugly, and should be avoided. If the API forces you to use them, replaceDWORDwithDWORD_PTRwhen you're dealing with... well, pointers. It was never correct to use (D)WORDthere in the first place IMHO.I don't think Windows will change its decision, ever. Too much trouble already.
Why was
intleft behind? Why does Venus rotate in the opposite direction? The answer to the first question is found here (I believe), the second is a bit more complicated ;)我认为您应该从无法留下任何可能需要的大小类型的角度来看待它，而不是将其视为“留下”。我认为编译器可以根据某些内部
__int32_t扩展类型来定义int32_t，但由于 C99 仍未得到广泛支持，对于应用程序来说，必须这样做将是一个巨大的痛苦。当构建系统在标准类型中找不到 32 位类型时，解决缺少int32_t定义的问题。无论您的本机字长是多少（例如，它是 Unicode 代码点值的唯一正确类型），拥有 32 位类型是必不可少的。出于同样的原因，将
short设为 32 位并将int设为 64 位也是不可行的：16 位类型对于许多事情（音频处理）至关重要第一个想到的。 （更不用说 Windows/Java 丑陋的 UTF-16 痴迷了..）真的，我认为 16 到 32 位和 32 到 64 位的转换根本没有可比性。抛弃 16 位就等于抛弃了一个系统，在这个系统中，日常生活中遇到的大多数数字都不适合基本类型，并且必须使用“远”指针之类的技巧来处理重要的数据集。另一方面，大多数应用程序对 64 位类型的需求最低。大型货币数字、多媒体文件大小/偏移、磁盘位置、高端数据库、对大型文件的内存映射访问等是一些想到的专门应用程序，但没有理由认为文字处理器需要数十亿个字符，或者一个网页需要数十亿个 html 元素。数值大小与物理世界、人类思维等现实的关系存在着根本的差异。
Instead of looking at this as
intbeing "left behind", I would say you should look at it in terms of not being able to leave behind any size type that might be needed. I suppose compilers could defineint32_tin terms of some internal__int32_textension type, but with C99 still not being widely supported, it would have been a major pain for apps to have to work around missingint32_tdefinitions when their build systems couldn't find a 32-bit type among the standard types. And having a 32-bit type is essential, regardless of what your native word size is (for instance it's the only correct type for Unicode codepoint values).For the same reason, it would not be feasible to have made
short32-bit andint64-bit: a 16-bit type is essential for many things, audio processing being the first that comes to mind. (Not to mention Windows'/Java's ugly UTF-16 obsession..)Really, I don't think the 16-to-32-bit and 32-to-64-bit transitions are at all comparable. Leaving behind 16-bit was leaving behind a system where most numbers encountered in ordinary, every-day life would not fit in a basic type and where hacks like "far" pointers had to be used to work with nontrivial data sets. On the other hand, most applications have minimal need for 64-bit types. Large monetary figures, multimedia file sizes/offsets, disk positions, high-end databases, memory-mapped access to large files, etc. are some specialized applications that come to mind, but there's no reason to think that a word processor would ever need billions of characters or that a web page would ever need billions of html elements. There are simply fundamental differences in the relationship of the numeric magnitudes to the realities of the physical world, the human mind, etc.