C标准支持平台列表 [英] List of platforms supported by the C standard

问题描述

有谁知道C标准，对此仍有活跃的开发工作支持的平台，但它们是：

Does anyone know of any platforms supported by the C standard, for which there is still active development work, but which are:

• 不补或


• 整数宽度不是32位或64位或


• 某些整数类型有填充比特或


• 如果您工作了2的补机，带符号的位模式上
  第1位和所有值的位零不是一个有效的负数或


• 整数签署无符号（反之亦然）的转换是不是通过逐字
  位模式的复制或


• 整数右移不是算术移位或


• 值比特的无符号类型的数量不是数
  在相应的符号类型值位+ 1


• 从更广泛的int类型为较小的类型转换是不是
  最左边位截断这将不适合

编辑：另外，如果有平台，在1995年至1998年这影响了C99决定将上述情况，但被停产了，我会在他们感兴趣也

Alternatively, if there are platforms in the period 1995 to 1998 which influenced the C99 decision to include the above, but which were discontinued, I would be interested in them also.

编辑：在C依据，已经这样说填充位：

The C rationale has this to say about padding bits:

的填充位是用户在访问一个无符号整数类型。例如，假设一个机
使用这32位int使用时，一对16位短裤（每个都有自己的符号位）来弥补一个32位int和下短的符号位被忽略。然后，作为一个32位有符号整数，存在在确定的32位有符号整数的值忽略的填充位（在32位的中间）。但是，如果该32位项目作为一个32位无符号整型处理，然后该填充位是给用户的程序可见。的C委员会被告知有这种方式工作的一台机器，这是一个原因是填充比特添加到C99。的

的脚注44和45提到，奇偶校验位可能是填充位。委员会不
知道一个整数范围内用户可访问的奇偶校验位的机器。因此，该
委员会是不知道把奇偶校验位作为填充位的机器。的

那么另一个问题是，什么是C99提到，机器？

So another question is, what is that machine which C99 mentioned?

编辑：看来，C99正考虑取消对1的补数的支持，并签署幅度：的 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm 的 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n873.htm （搜索6.2.6.2）

It seems that C99 was considering removing support for 1's complement and signed magnitude: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n873.htm (search for 6.2.6.2)

推荐答案

我最近在这仍然使用一个版本的PDP-10，以及海湾合作委员会的该平台端口的公司工作。我们用10有几个你列出的属性：

I recently worked at a company which still used a version of the PDP-10, and a port of GCC to that platform. The 10 we used had a few of the attributes you list:

• 整数是不是32位或64位，他们是36位的。


• 填充位用于一些重新presentations。对于扩展precision整数（例如长长型的），底层再presentation为72位，其中每个36位字的有符号位。

在除了上述不寻常的属性，有问题的是，该机有几个不同的字节寻址机制。在6-12位宽可能是由这表明它的宽度和正在使用字对齐地址本身使用特殊位寻址范围宽字节。要重新present一个char *人们可以使用重新presentation这将解决8位字节，在这个词所有这些都是左对齐，留下4位，其中没有每个36位字解决的。备选9位字节可用于这将适合均匀成36位字。无论这样的方法已经有缺陷的便携性，但是当时我离开它被认为是更实际的使用，因为使用TCP / IP网络和标准的设备互动的8位字节往往觉得而言16，24或32比特字段其中也有8位字节的底层结构。

In addition to the above unusual attributes, there was the issue that the machine had several different byte addressing mechanisms. Bytes with widths in the range of 6-12 bits wide could be addressed by using special bits in the address itself which indicated which width and word alignment was being used. To represent a char* one could use a representation which would address 8-bit bytes, all of which were left-aligned in the word, leaving 4-bits in each 36-bit word which were not addressed at all. Alternatively 9-bit bytes could be used which would fit evenly into the 36-bit word. Both such approaches had there pitfalls for portability, but at the time I left it was deemed more practical to use the 8-bit bytes because of interaction with TCP/IP networking and standard devices which often think in terms of 16, 24, or 32-bit fields which also have an underlying structure of 8-bit bytes.

据我所知，这个平台仍然被用于产品领域，并有在这家公司编译器开发者保持GCC的相对较新的版本是最新的，为了让这个平台上进一步C开发。

As far as I know this platform is still being used in products in the field, and there is a compiler developer at this company keeping relatively recent versions of GCC up to date in order to allow for further C development on this platform.

这篇关于C标准支持平台列表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！