是否存在C的非二进制补码实现?

pax*_*blo 41 c iso representation negative-number language-lawyer

我们毫无疑问地知道,ISO C标准(以及C++,我认为,虽然我对C方面更感兴趣)允许签名数字的三个基础表示:

  • 二补;
  • 补充; 和
  • 符号/幅值.

维基百科的条目表明,60年代的IBM 7090使用了标志/幅度,PDP-1,CDC 160A和UNIVAC 1100使用的是补充,所有这些都可以追溯到60年代.

是否有其他任何具有这些替代表示的C(或底层硬件)实现,这些实现比五十年前更新了(它们是什么)?

对于不再存在的机器,保持某种标准似乎有点浪费.

Mik*_*our 33

我能找到的最新例子是基于UNIVAC 的UNISYS 2200系列,带有补码运算.各种型号是在1986年至1997年间生产的,但操作系统仍在积极开发,直到2015年.他们也有一个C编译器,因为看到这里.

它们似乎可能仍然在今天使用.

  • 出于兴趣,Unisys 2200*for*是什么?取代破旧的Univacs运行任务关键型遗留应用程序,还是有新的开发? (7认同)
  • OS 2200的C编译器在其"补偿模式"中似乎不符合标准,最大无符号值(UINT_MAX)是"2 ^ N-2"而不是"2 ^ N-1".看起来这样做是为了在不更改位模式的情况下将signed转换为unsigned int时,0x3FFFF或minus零不是有效值.(C99和C11也就是说,_may_可以符合C89,但只是在__并不是没有针对it_方式的法律,很明显无条件的预期是什么.) (3认同)
  • Unisys在去年(2011年)提供[硬件运行OS2200](http://www.unisys.com/unisys/theme/index.jsp?id=1120000970018010225&pid=16000034). (2认同)
  • 即使编译器在2015年更新,它似乎也不符合过去C89的任何标准; 除此之外,它没有任何超过36位的无符号类型. (2认同)

R..*_*R.. 6

我没有任何确凿的证据证明没有,但我从未见过.据我所知,所有非二进制补码硬件在C标准化之前就已经过时了.

收集证据的最佳方法可能是在与非二元补充系统相关的标准中寻找相互冲突的要求和其他彻底的错误.如果从未创建过这样的实现,那么当某人实际尝试制作一个实体时,规范中可能会出现疏忽.

  • 或者彻底地做到这一点:编写一个具有最小字节码并使用1s补码和/或符号幅度的VM.如果它们中的任何一个具有名义上的支持,则实现GCC或LLVM后端,否则实现完整的C实现.这两个问题都回答了问题("是的,我现在知道非二进制补充实现")并且如果标准确实存在疏忽,则有机会提交已考虑的缺陷报告.如果任何缺陷是关键的,那么在下一个标准中强制要求2的补充是弹药. (9认同)
  • @SteveJessop:这是一个很酷的方法,但它可能比通常用于回答SO问题的工作稍微多一些;-) (9认同)
  • 我猜GCC至少假设二进制补码和8位字节.好吧,我只想说"定义",而不是"假设",因为编译器需要定义这些概念.即使在打算使用sign/mag或者补码的机器上,编译器也可以轻松地选择仅通过使用无符号算术指令而不是带符号的算术指令来提供二进制补码环境...... (4认同)
  • @JoachimSauer:我承认我个人不能为此烦恼. (2认同)
  • @ams:我的目标没有操作系统,它只是一些玩具字节码解释器.但是如果海湾合作委员会假设2的补充,那么肯定,这对我的假设项目没有好处. (2认同)