计算机字长与字节大小的发展历程

这并非我通常的博客内容，但这里的材料太多，甚至不适合在 Mastodon 上发布。基本问题是为什么各种早期微型计算机——以及今天的所有计算机——都使用 8 位字节。

这些材料很多基于个人经验；部分内容来自我从导师 Fred Brooks 那里学习的计算机架构课程（可能还有其他课程）。

有三个起点需要记住。首先，穿孔卡数据处理比计算机古老得多：它可以追溯到 19 世纪末的 Hollerith。当计算机化开始时，它必须适应这些较旧的“数据库”。其次，早期计算机的存储量按今天标准来看非常小，包括 RAM 和大容量存储（可能是磁盘或磁带）。第三，直到 1960 年代中期，计算机要么是“商用”的，要么是“科学”的，其架构适合这些用途。

穿孔卡处理受到严重限制。穿孔卡（至少是 IBM 类型）有 80 列，每列 12 行。考虑到前计算机时代数据处理的工作方式，强烈希望将给定记录的所有数据保存在单张卡片上。这意味着压缩数据的方法非常宝贵，且需要使用基于软件的算法进行压缩。最简单的方法是在卡片列中打额外的孔。考虑一个包含单个数字“3”的列，这由单列的 3 行中的一个孔表示。因此有 10 行保留给数字——但在数字字段中，11 行和 12 行未被使用。您可以在该列中编码另外两个位，只要“编程”知道，例如，具有 12-3 穿孔的列实际上是 12 穿孔和数字 3，而不是字母 C。显然，10 个数字行加上两个“区域”行给我们 40 个可能的字符；计算机化时又添加了几个。

让我们看看这样的计算机。底层技术是二进制的，因为构建查看开/关的电路比查看 10 个不同电压级别要容易得多。但在读取卡片时，您必须单独保留两个区域位，因为它们的含义取决于应用程序。因此，它们使用 6 位字符：两个区域位，加上四个位用于单个数字。但在这四个位中可以容纳 16 个可能值，而不仅仅是 10 个，因此那个时代的机器实际上有 64 位字符集。在纯数字字段中，区域位用于符号位和（有时）某种字段结束标记，但这与我讨论的内容无关，因此我不再赘述。重要的是每列必须作为一个字符读入，或多或少未经解释。

将数字表示为（实际上是）十进制字符的字符串对于商业数据处理也是理想的，因为您经常处理金钱，即美元和美分或法郎和生丁。事实证明，$.10 无法用二进制表示：1/10 在二进制中是重复字符串，就像 1/3 在十进制中一样，CFO 和银行家不喜欢在有限位数截断值所导致的不准确性。（英镑、先令和便士？别提了！）当时的商用计算机会对长串十进制数字进行算术运算。

科学计算机有不同的约束。它们经常处理不精确的数字（在计算轨道时地球的确切直径是多少？），并且必须处理对数、三角函数等。此外，许多计算本质上是近似的：泰勒级数不会产生精确答案（除非偶然），甚至在理论上可能不可能。（π的确切值是多少？它不仅无理，而且超越。）但还有其他约束。有时，科学家和工程师处理非常大的数字；其他时候，他们处理非常小的数字。此外，他们需要合理的精度，尽管需要多少精度取决于问题。浮点数在内部以科学记数法表示：指数（通常是二进制）和尾数。因此有两个关键参数：尾数中的位数，转化为存储数字的精度，以及指数中的位数，转化为范围。（当然，两个字段都包括某种形式的符号位。）考虑到这些约束，以及具有 6 位字符的商业数据处理首先出现，使用 36 位字是自然的：足够的精度和范围位，并且如果这样做，能够容纳六个字符。

这就是 IBM S/360 系列在 1961 年开始设计时的状况。但 360 的目标之一是拥有一个可以同时进行科学和商业计算的统一架构。仍然需要支持那些旧的 BCD 数据库，无论它们仍在穿孔卡上还是已迁移到磁带，并且仍然需要支持十进制算术。基本设计是支持科学工作和通用计算的内存到寄存器算术，以及商业计算的存储到存储十进制算术。这显然意味着混合字节/字架构。但字节应该多大？一个派系支持 6 位字节和 24 位或 36 位字；另一个支持 8 位字节和 32 位字。最终，Brooks 做出了决定：8 位字节允许小写字母，他预见到这对于允许字符处理将变得重要。（旁白：Brooks 除了是个好人外，还是个聪明人。令人深思的是，他被任命领导 S/360 设计项目，这是 IBM 的赌注，当时他只有 30 岁，这就在他之前的项目，8000 系列科学计算机被取消之后。我 30 岁时甚至还没毕业！）

从 36 位减少到 32 位用于浮点数具有挑战性：精度有所损失。您可以使用双精度浮点——64 位——但这消耗了存储，而存储是昂贵的。事实上，8 位字节也很昂贵：每个字符多 33%的位。（IBM 进行了许多模拟和分析以确认 32 位通常足够。）但 Brooks 对小写字母需求的愿景已得到充分证实。（其他字符集而非美国拉丁字母？当时并未真正进入人们的视野，这是不幸的。但当时很难做到像 Unicode 这样的东西。Unicode 的最低平面基于 ASCII，而非 IBM 的 EBCDIC。IBM 内部的许多人希望为 S/360 系列转向 ASCII（在程序状态字中甚至支持 ASCII 字节而非 EBCDIC 字节当处理十进制算术时），但主要客户恳求 IBM 不要这样做——记住那些仍然存在且仍然无法在上下文无关方式中转换的烦人区域穿孔？）

8 位字节还有其他，尽管较小的优势。如果您试图创建位数组，能够截取低 3 位并使用它们索引到字节中是很好的。但 Brooks 本人表示，他决策的主要原因是支持小写字母。（旁白：S/360 的另一位架构师 Gerritt Blaauw 在 UNC Chapel Hill 度过了一个学期，我当时是那里的研究生，我从他那里学习了一门计算机设计课程。行业媒体有传言称 IBM 将在未来的计算机中转向 9 位字节。我碰巧听到他和 Brooks 关于这个传言的对话。两人都不知道这是否属实，但他们都认为这将是不幸的，考虑到他们为 8 位字节奋斗的艰辛。）USASCII 很好地适应 7 位，但这是一个非常尴尬的字节大小。上平面用于各种其他字母表的字符。然而，这种用法在很大程度上已被 Unicode 取代。归根结底，自 S/360 以来，从未有充分理由使用除 8 位以外的任何字节大小。在 IBM 系统上，您有 EBCDIC，一个 8 位字符集。在其他所有系统上，您有 ASCII，它很好地适应 8 位且更具国际性。

字大小更与硬件相关。真正的问题，尤其是在缓存出现之前，是内存总线的宽度。宽总线对性能更好，但当然更昂贵。S/360 最初计划有五个型号，从低端 360/30 到 360/70，共享相同的指令集。事实证明，360/50 是价格/性能和利润的最佳点——它具有 32 位内存总线。如果您试图进行 32 位加法，您真的希望内存操作数在 4 字节边界上对齐，否则您必须进行两次内存提取。那么，32 位是自然的字大小，也是寄存器的大小。您可以进行半字提取，但这很容易；您只需丢弃不需要的那一半字。双精度 64 位操作数需要两次提取，但在具有 64 位总线的高端机器上，如果操作数在 8 字节边界上对齐，则只需一次提取。而在 IBM Z 系列，S/360 的现代继承者上？字仍然是 32 位，因为术语已确立。一对 64 位寄存器一起被称为“四字”。也就是说，“字”是什么是由架构的原始历史定义的；此后，它可能是历史性的。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

办公AI智能小助手

公众号二维码

网络安全技术点滴分享