计算机字长与字节大小的发展历程
这并非我通常的博客内容，但这里的材料太多，甚至不适合在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智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
公众号二维码
公众号二维码
