标准委员会关注的异国架构

我知道C和C ++标准留下了语言实现定义的许多方面，只是因为如果存在具有其他特征的体系结构，那么将很难或不可能为其编写符合标准的编译器。

我知道40年前，任何计算机都有其自己的独特规范。但是，我不知道今天使用的任何架构在哪里：

• CHAR_BIT != 8
• signed 不是两个的补码（我听说Java对此有问题）。
• 浮点不符合IEEE 754（编辑：我的意思是“不是采用IEEE 754二进制编码”）。

我问的原因是，我经常向人们解释，C ++不要求其他任何低级方面（例如固定大小的类型^†）是很好的。很好，因为与“其他语言”不同，它可以使您的代码在正确使用时可移植（编辑：因为可以将其移植到更多体系结构中，而无需模拟机器的低级方面，例如，符号+幅值体系中的二进制补码算法） 。但是我很难为自己不能指出任何特定的体系结构。

所以问题是：哪些架构具有上述特性？

† uint*_t是可选的。

看看这个

Unisys ClearPath Dorado服务器

为尚未迁移所有Univac软件的人们提供向后兼容性。

关键点：

• 36位字
• CHAR_BIT == 9
• 一个人的补
• 72位非IEEE浮点
• 代码和数据的单独地址空间
• 字寻址
• 没有专用的堆栈指针

虽然不知道他们是否提供C ++编译器，但可以。

现在，指向他们最新版本的C手册的链接已经浮出水面：

Unisys C编译器编程参考手册

第4.5节列出了具有9、18、36和72位的数据类型。

您的假设均不适用于大型机。首先，我不知道使用IEEE 754的大型机：IBM使用基数16的浮点，而两个Unisys大型机都使用基数8。Unisys的机器在许多其他方面都有些特殊：Bo提到了2200。架构，但MPS架构甚至更陌生：48位标记的单词。（单词是否为指针取决于单词中的某个位。）并且设计了数字表示形式，以使浮点数与整数算术运算之间没有真正的区别：浮点数以8为底；它不需要规范化，并且与我所见过的所有其他浮点不同，它将小数点放在尾数的右边而不是左边，并对指数（除尾数外）使用带符号的大小。结果是，整数浮点值具有（或可以具有）与带符号的幅度整数完全相同的位表示形式。而且没有浮点运算指令：如果两个值的指数都为0，则该指令执行积分运算，否则执行浮点运算。（体系结构中标记哲学的延续。）这意味着int 可能占用48位，其中8位必须为0，否则该值将不会被视为整数。

在浮点实现中，完全符合IEEE 754的情况很少。在这方面削弱规范可以进行很多优化。

例如，子规范在x87和SSE之间的支持差异。

源代码中分开的诸如乘法和加法运算之类的优化也略有改变结果，但是在某些体系结构上是很好的优化。

或在x86上，严格的IEEE遵从性可能要求设置某些标志或在浮点寄存器与常规内存之间进行其他传输，以强制其使用指定的浮点类型而不是其内部80位浮点。

而且某些平台根本没有硬件浮动，因此需要在软件中进行仿真。而且，IEEE 754的某些要求在软件中实现可能会很昂贵。特别是舍入规则可能是个问题。

我的结论是，如果您不总是想保证严格的IEEE遵从性，那么您就不需要异国情调的架构来适应各种情况。因此，很少有编程语言可以保证严格遵守IEEE。

我发现此链接列出了其中的某些系统CHAR_BIT != 8。它们包括

一些TI DSP具有 CHAR_BIT == 16

BlueCore-5芯片（来自Cambridge Silicon Radio的蓝牙芯片）具有CHAR_BIT == 16。

当然，关于堆栈溢出还有一个问题：哪些平台具有8位字符以外的内容

对于非二进制补码系统，有关于 comp.lang.c ++。moderated的有趣读物。总结：有些平台具有补码或符号和大小表示。

我相当确定VAX系统仍在使用中。它们不支持IEEE浮点数。他们使用自己的格式。Alpha支持VAX和IEEE浮点格式。

尽管更新的Cray系统使用IEEE，但Cray矢量机（如T90）也具有自己的浮点格式。（我使用的T90几年前已经退役；我不知道是否仍在使用中。）

T90还具有/具有一些有趣的指针和整数表示形式。本机地址只能指向64位字。C和C ++编译器的CHAR_BIT == 8（这是必需的，因为它运行的是Unicos，一种Unix风格，并且必须与其他系统进行互操作），但是本机地址只能指向64位字。所有字节级操作是由编译器合成，和一个void*或char*存储一个字节的字的高阶3个比特的偏移。而且我认为某些整数类型具有填充位。

IBM大型机是另一个示例。

另一方面，这些特定的系统并不一定要排除对语言标准的更改。对于将C编译器升级到C99，Cray没有表现出特别的兴趣。大概是同样的情况适用于C ++编译器。这可能是合理的收紧不填充比特托管实现的要求，如要求CHAR_BIT == 8，IEEE格式浮点如果不是全部语义，二进制补码符号整数。旧系统可以继续支持较早的语言标准（当C99推出时C90不会消失），并且对于独立的实现（嵌入式系统）（如DSP）的要求可能会更宽松。

另一方面，将来的系统可能有充分的理由来做今天被认为是异国情调的事情。

CHAR_BITS

根据gcc的源代码：

CHAR_BIT是16对位1750A，dsp16xx架构。
CHAR_BIT是dsp56k架构的24位。是c4x架构的位。
CHAR_BIT32

您可以通过执行以下操作轻松找到更多信息：

find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"

要么

find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"

如果CHAR_TYPE_SIZE已正确定义。

符合IEEE 754

如果目标体系结构不支持浮点指令，则gcc可能会默认生成不符合标准的软件后备代码。不仅如此，-funsafe-math-optimizations还可以使用特殊选项（例如女巫也禁用符号保留为零）。

直到最近，IEEE 754二进制表示形式在GPU上才很常见，请参阅GPU浮点偏执狂。

编辑：注释中提出了一个问题，即GPU浮点是否与通常的计算机编程相关，而与图形无关。当然好！当今工业上计算出的大多数高性能都是在GPU上完成的。该列表包括AI，数据挖掘，神经网络，物理模拟，天气预报等。一位在评论节目，为什么链接：一个数量级浮点图形处理器的优势。

我想补充一件事，这与OP问题更相关：当GPU浮点不是IEEE且没有像今天的OpenCL或CUDA这样的API来编程GPU时，人们在10-15年前做了什么？信不信由你，早期的GPU计算先驱设法在没有API的情况下对GPU进行编程！我在公司里遇到了其中一位。这就是他的工作：他将需要计算的数据编码为图像，并用像素表示他正在处理的值，然后使用OpenGL执行他需要的操作（例如“高斯模糊”以正态分布表示卷积）等），然后将生成的图像解码回结果数组。而且这仍然比使用CPU快！

诸如此类的事情促使NVidia最终使内部数据与IEEE二进制兼容，并引入了面向计算而非图像处理的API。