1字节!= 8位的系统？

Question

1字节!= 8位的系统？

Xeo*_*Xeo 85 c c++ history byte computer-architecture

我一直在读句子

不要依赖大小为8位的1字节

使用CHAR_BIT而不是8作为常量来转换位和字节

等等.今天有什么现实生活系统,这是真的吗？ _{(我不确定C和C++之间是否存在差异,或者它是否与语言无关.如果需要,请重新加入.)}

Answer 1

Jer*_*fin 68

在较旧的机器上,小于8位的代码相当普遍,但是大多数代码已经死了多年并且已经消失了.

C和C++规定至少 8位char,至少可以追溯到C89标准.[编辑:例如,C90,§5.2.4.2.1要求CHAR_BIT> = 8且UCHAR_MAX> = 255. C89使用不同的部分编号(我相信这将是§2.2.4.2.1)但内容相同].它们将"char"和"byte"视为基本同义[编辑:例如,CHAR_BIT描述为:"不是位域(字节)的最小对象的位数".]

然而,当前的机器(主要是DSP),其中最小的类型大于8位 - 最少12,14或甚至16位是相当普遍的.Windows CE大致相同:它的最小类型(至少使用Microsoft的编译器)是16位.但是,他们不会将char16位视为 - 而是采用(不符合)方法,根本不支持完全命名的类型char.

哇+1教我一些关于WinCE如何破碎的新内容...... (25认同)
@Jerry,你确定`char`和WinCE？我为WinCE 5.0/x86和/ ARM写了一点; `char`类型没有任何问题.他们所做的是删除char-size版本的**Win32 API**(所以GetWindowTextW在那里,但GetWindowTextA不是等等) (2认同)
@atzz：`char` 的可用性（或缺乏它）显然取决于编译器，而不是操作系统本身。我（至少认为我）记得 CE 的早期编译器之一缺少 `char`，但是自从我为 CE 编写任何代码以来已经有一段时间了，所以我无法真正评论任何当前（或接近它）的内容. (2认同)

Answer 2

Joh*_*ohm 23

今天,在x86处理器上的C++世界中,依赖于8位的一个字节是非常安全的.字大小不是2(8,16,32,64)的幂的处理器非常罕见.

它并非总是如此.

Control Data 6600(及其兄弟)中央处理器使用60位字,一次只能寻址一个字.从某种意义上说,CDC 6600上的"字节"是60位.

DEC-10字节指针硬件使用任意大小的字节.字节指针包括以位为单位的字节大小.我不记得字节是否可以跨越字边界; 我认为它们不能,这意味着如果字节大小不是3,4,9或18位,那么每个字会有一些浪费位.(DEC-10使用了36位字.)

"今天,在x86处理器上的C++世界" - 您可能想与TI,ADI公司(具有16位DSP),Freescale/NXP(24位DSP),ARM,MIPS(均不是x86)等进行对话事实上,x86是销售的少数架构和设备.但是,**二进制**数字计算机几乎没有**三位数(/等)数字. (4认同)
当我做6600时,在我的大学时代,角色仍然只有6位.PASCAL程序员必须知道12位PP字大小,因为行尾仅发生在12位边界.这意味着在行中的最后一个非空白字符之后可能会或者可能不会出现空白,并且在30多年之后我才开始思考这个问题. (3认同)
CDC上的字符串通常存储在字中10位字符,因此将其视为具有6位字节(通常以10字节块分配的字符串)更为合理.当然,从C或C++的角度来看,不允许使用6位字节,因此您不得不将它们加倍并使用12位字作为"字节"(这仍然可以很好地工作) - PPU是12位处理器,CPU和PPU之间的通信是以12位块完成的. (2认同)

Answer 3

R..*_*R.. 14

除非您编写的代码可能对DSP有用,否则您完全有权假设字节为8位.全世界可能都不是VAX(或英特尔),但全世界都必须进行通信,共享数据,建立通用协议等等.我们生活在基于八位字节构建的协议的互联网时代,任何字节不是八位字节的C实现都将很难使用这些协议.

值得注意的是POSIX和Windows都有(并且要求)8位字节.这涵盖了100%有趣的非嵌入式机器,而且现在也有很大一部分非DSP嵌入式系统.

如果`char`大于8位,则不能存在`uint8_t`****,因为那时`uint8_t`会有填充位,这是不允许的. (10认同)
他们不能.`getc`和`putc`必须保留`unsigned char`值往返,这意味着你不能只在`char`中有"额外的位"而不能读/写. (4认同)
@R .. 我不明白你的“他们不能[在互联网上进行交流]”评论我不明白的一件事是，你引用了`getc`和`putc`，但那些是高度相关的访问互联网的问题？世界上几乎所有东西都不是通过标准 C 库之外的接口访问 Internet 的吗？最后我检查过，如果不首先通过系统特定的接口，您甚至无法获得指向网络连接的 `stdio.h` 兼容对象，对吗？那么有什么理由说明`getc`/etc 的细节会阻止访问互联网吗？ (2认同)

Answer 4

Dan*_*ite 7

来自维基百科:

首先选择一个字节的大小为现有电传打字机代码的倍数,特别是美国陆军(Fieldata)和海军使用的6位代码.1963年,为了终止美国政府不同部门使用不兼容的电传打字机代码,采用7位代码ASCII作为联邦信息处理标准,使6位字节在商业上已经过时.在20世纪60年代早期,AT&T首先在长途干线上引入了数字电话.这些使用8位μ律编码.这笔巨额投资有望降低8位数据的传输成本.使用8位代码进行数字电话也导致8位数据"八位字节"被用作早期互联网的基本数据单元.

这不是问题的答案,只是一个模糊的相关历史记录. (6认同)

Answer 5

Ale*_*ler 6

作为主流平台的平均程序员,你就不会需要太担心一个字节不是8位.但是,我仍然CHAR_BIT在我的代码和assert(或更好static_assert)任何依赖8位字节的位置使用常量.这应该让你安全.

(我不知道任何相关的平台,它不成立).

除了安全之外,`CHAR_BIT`是自我记录的.我在SO上了解到一些嵌入式平台显然有16位`char`. (2认同)

Answer 6

AnT*_*AnT 5

首先,位数char不正式依赖于"系统"或"机器",即使这种依赖性通常是由常识暗示的.位数char仅取决于实现(即在编译器上).char对于任何"普通"系统或机器,实现编程器的位数都超过8位是没有问题的.

其次,有几个嵌入式平台sizeof(char) == sizeof(short) == sizeof(int),每个都有16位(我不记得这些平台的确切名称).此外,众所周知的Cray机器具有类似的特性,所有这些类型都具有32位.

归档时间：	14 年，7 月前
查看次数：	24988 次
最近记录：	12 年，1 月前