mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-03 23:40:14 +08:00
Xingyu Wang
parent
4de6686e94
commit
87aee0de0f
@ -0,0 +1,213 @@
|
||||
[#]: subject: "Some possible reasons for 8-bit bytes"
|
||||
[#]: via: "https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes/"
|
||||
[#]: author: "Julia Evans https://jvns.ca/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "ChatGPT"
|
||||
[#]: reviewer: "wxy"
|
||||
[#]: publisher: "wxy"
|
||||
[#]: url: "https://linux.cn/article-15861-1.html"
|
||||
|
||||
为什么计算机采用 8 位字节
|
||||
======
|
||||
|
||||
![][0]
|
||||
|
||||
我正在制作一份有关计算机以二进制表示事物的小册子，有人问我一个问题 - 为什么 x86 架构使用 8 位字节？为什么不能是其他大小呢？
|
||||
|
||||
对于类似这样的问题，我认为有两种可能性：
|
||||
|
||||
- 这是历史原因造成的，其他尺寸（如 4、6 或 16 位）同样有效。
|
||||
- 8 位是客观上的最佳选择，即使历史发展不同，我们仍然会使用 8 位字节。
|
||||
- 一些混合 1 和 2 的因素。
|
||||
|
||||
我对计算机历史并不是非常着迷（与阅读计算机文献相比，我更喜欢使用计算机），但我总是很好奇计算机事物今天的方式是否存在本质原因，或者它们大多是历史偶然的结果。因此，我们将谈论一些计算机历史。
|
||||
|
||||
作为历史偶然性的一个例子：DNS 有一个 `class` 字段，它有 5 种可能的值（`internet`、`chaos`、`hesiod`、`none` 和 `any`）。 对我来说，这是一个明显的历史意外的例子 - 如果我们今天重新设计 DNS 而不必担心向后兼容性，我无法想象我们会以相同的方式定义类字段。我不确定我们是否会使用 `class` 字段！
|
||||
|
||||
这篇文章没有明确的答案，但我在 [Mastodon][1] 上提问，并找到了一些潜在的 8 位字节原因。我认为答案是这些原因的某种组合。
|
||||
|
||||
#### 字节和字有什么区别？
|
||||
|
||||
首先，本文中经常提到 “<ruby>字节<rt>byte</rt></ruby>” 和 “<ruby>字<rt>word</rt></ruby>”。它们有什么区别？我的理解是：
|
||||
|
||||
- **字节的大小** 是你可以寻址的最小单元。例如，在我的计算机上，程序中的 `0x20aa87c68` 可能是一个字节的地址，然后 `0x20aa87c69` 是下一个字节的地址。
|
||||
- **字的大小** 是字节大小的某个倍数。我对此困惑了多年，维基百科的定义非常模糊（“字是特定处理器设计使用的自然数据单元”）。我最初认为字大小与寄存器大小相同（在 x86-64 上为 64 位）。但是根据 [英特尔架构手册][2] 的第 4.1 节（“基本数据类型”），在 x86 上，虽然寄存器是 64 位的，但一个字是 16 位的。因此我困惑了 —— 在 x86 上，一个字是 16 位还是 64 位？它可以根据上下文而有不同的含义吗？这是怎么回事？
|
||||
|
||||
现在让我们来讨论一些使用 8 位字节的可能原因！
|
||||
|
||||
#### 原因 1：将英文字母适配到 1 字节中
|
||||
|
||||
[维基百科文章][3] 表示 IBM System/360 于 1964 年引入了 8 位字节。
|
||||
|
||||
在管理该项目的 Fred Brooks 的一段 [视频采访][4] 中，他讲述了原因。以下是我转录的一些内容：
|
||||
|
||||
> …… 6 位字节在科学计算中确实更好，而 8 位字节则更适合商业计算，每个字节都可以针对另一个字节进行调整，以使两种字节互相使用。
|
||||
>
|
||||
> 因此，这变成了一个高管决策，我决定根据 Jerry 的建议采用 8 位字节。
|
||||
>
|
||||
> ……
|
||||
>
|
||||
> 我在我的 IBM 职业生涯中做出的最重要的技术决策是为 360 选择 8 位字节。
|
||||
>
|
||||
> 我相信字符处理将变得重要，而不是十进制数字。
|
||||
|
||||
使用 8 位字节处理文本很有道理：2^6^ 为 64，因此 6 位不足以表示小写字母、大写字母和符号。
|
||||
|
||||
为了使用 8 位字节，System/360 还引入了 [EBCDIC 编码][5]，这是一种 8 位字符编码。
|
||||
|
||||
接下来在 8 位字节历史上重要的机器似乎是 [英特尔 8008][6]，它设计用于计算机终端（Datapoint 2200）。终端需要能够表示字母以及终端控制代码，因此使用 8 位字节对其来说很有意义。[计算机历史博物馆上的 Datapoint 2200 手册][7] 在第 7 页上说 Datapoint 2200 支持 ASCII（7 位）和 EBCDIC（8 位）。
|
||||
|
||||
#### 为什么 6 位字节在科学计算中更好？
|
||||
|
||||
我对这条 “6 位字节在科学计算中更好” 的评论很好奇。以下是 [Gene Amdahl 的一段采访摘录][8]：
|
||||
|
||||
> 我原本希望采用 24 和 48 而非 32 和 64，因为这将为我提供一个更合理的浮点系统。因为在浮点运算中，使用 32 位字大小时，你必须将指数保持在 8 位中用于指数符号，并且要使其在数字范围上合理，你必须每次调整 4 个位而不是单个位。因此，这将导致你比使用二进制移位更快地失去一些信息。
|
||||
|
||||
我完全不理解这条评论 - 如果你使用 32 位字大小，为什么指数必须是 8 位？如果你想要，为什么不能使用 9 位或 10 位？但这是我在快速搜索中找到的全部内容。
|
||||
|
||||
#### 为什么大型机使用 36 位？
|
||||
|
||||
与 6 位字节相关的问题是：许多大型机使用 36 位字大小。为什么？在维基百科的 [36 位计算][9] 文章中有一个很好的解释：
|
||||
|
||||
> 在计算机问世之前，即需要高精度科学和工程运算的领域，使用的是十位数码电动机械计算器……这些计算器每位数码均有一个专用按键，操作人员在输入数字时需要用到所有手指，因此，虽然有些专业计算器有更多位数码，但这种情况是个实际的限制。
|
||||
>
|
||||
> 因此，早期针对相同市场的二进制计算机通常使用 36 位字长度。这足以表示正负整数最高精度到十位数字（最小应为 35 位）。
|
||||
|
||||
因此，这种 36 位大小似乎是基于 $$log_2(20000000000)$$ 的，它等于 34.2。嗯。
|
||||
|
||||
我猜这个原因是在 50 年代，计算机非常昂贵。因此，如果您想要你的计算机支持十位十进制数字，你将设计它恰好具有足够的位来执行此操作，而不会更多。
|
||||
|
||||
现在计算机更快更便宜，因此，如果您想要出于某种原因表示十位十进制数字，你只需使用 64 位即可 - 浪费一点空间通常并不会有太大问题。
|
||||
|
||||
还有人提到，一些具有 36 位字大小的计算机可以让你选择字节大小 - 根据上下文，你可以使用 5 或 6 或 7 或 8 位字节。
|
||||
|
||||
#### 原因 2：与二进制编码的十进制一起工作
|
||||
|
||||
20 世纪 60 年代，有一种流行的整数编码叫做 <ruby>二进制编码的十进制<rt>binary-coded decimal</rt></ruby>（缩写为 [BCD][10]），它将每个十进制数字编码为 4 位。
|
||||
|
||||
例如，如果你想要编码数字 `1234`，在 BCD 中，它会是这样的：
|
||||
|
||||
```
|
||||
0001 0010 0011 0100
|
||||
```
|
||||
|
||||
因此，如果你想要能够轻松地与二进制编码的十进制一起工作，你的字节大小应该是 4 位的倍数，比如 8 位！
|
||||
|
||||
#### 为什么 BCD 很流行？
|
||||
|
||||
这个整数表示方法对我来说真的很奇怪 —— 为什么不用更有效率的二进制来存储整数呢？在早期的计算机中，效率非常重要！
|
||||
|
||||
我最好的猜测是，早期的计算机没有像我们现在这样的显示器，所以一个字节的内容被直接映射到开关灯上。
|
||||
|
||||
这是来自维基百科一个带有一些亮灯的 IBM 650 显示器的图片（[CC BY-SA 3.0][12] 许可）：
|
||||
|
||||
![][13]
|
||||
|
||||
因此，如果你想让人们能够相对容易地从二进制表示中读取十进制数，这样做就更有意义了。我认为，今天 BCD 已经过时了，因为我们拥有显示器，并且我们的计算机可以将用二进制表示的数字转换为十进制，并显示它们。
|
||||
|
||||
此外，我想知道，“<ruby>四位<rt>nibble</rt></ruby>”（意为 “4 位”）这个词是不是来自 BCD 的。在 BCD 的上下文中，你经常会引用半个字节（因为每个十进制数字是 4 位）。所以有一个 “4 位” 的词语是有意义的，人们称 4 个位为 “<ruby>四位<rt>nibble</rt></ruby>”。今天，“四位” 对我来说感觉像是一个古老的词汇，除了作为一个趣闻我肯定从未使用过它（它是一个很有趣的词！）。维基百科关于 “[四位][14]” 的文章支持了这个理论：
|
||||
|
||||
> “四位” 用来描述存储在 IBM 大型计算机中打包的十进制格式（BCD）中数字的位数。
|
||||
|
||||
还有一个人提到 BCD 的另一个原因是 **金融计算**。今天，如果你想存储美元金额，你通常只需使用整数的分数，然后在需要美元部分时除以 100。这没什么大不了的，除法很快。但显然，在 70 年代，将一个用二进制表示的整数除以一个 100 是非常慢的，所以重新设计如何表示整数，以避免除以 100 是值得的。
|
||||
|
||||
好了，关于 BCD 就说这么多。
|
||||
|
||||
#### 原因 3：8 是 2 的幂？
|
||||
|
||||
许多人说，CPU 的字节大小是 2 的幂次方很重要。我无法确定这是真的还是假的，而且我对 “计算机使用二进制，所以 2 的幂次方很好” 这种解释感到不满意。这似乎非常合理，但我想深入探讨一下。而且从历史上看，肯定有很多使用字节大小不是 2 的幂次方的机器，例如（来自 [这个来自 Stack Exchange 上复古计算版块的帖子][15]）：
|
||||
|
||||
- Cyber 180 大型机使用 6 位字节
|
||||
- Univac 1100/2200 系列使用 36 位字长
|
||||
- PDP-8 是一台 12 位计算机
|
||||
|
||||
一些我听到的关于 2 的幂次方很好的原因我还没有理解：
|
||||
|
||||
- 一个单词中的每个位都需要一个总线，而你希望总线数量是 2 的幂次方（为什么？）
|
||||
- 很多电路逻辑容易针对分而治之的技术（我需要一个例子来理解这个）
|
||||
|
||||
对我更有意义的原因是：
|
||||
|
||||
- 它使设计“时钟分频器”更容易，这些分频器可以测量“在这条线路上发送了 8 位”，分别基于减半进行操作 - 你可以将 3 个减半时钟分频器串联起来。[Graham Sutherland][16] 告诉我这个，他制作了这个非常酷的 [分频器模拟器][17]，展示了这些分频器的工作原理。该网站（Falstad）还有很多其他示例电路，似乎是制作电路模拟器的一个非常酷的方式。
|
||||
- 如果你有一个指令可以将字节中的特定位清零，则如果你的字节大小为 8（2 的 3 次方），你可以只使用 3 位指令来指示哪一位。x86 似乎没有这样做，但 [Z80 的位测试指令][18] 是这样做的。
|
||||
- 有人提到一些处理器使用 [进位前瞻加法器][19]，它们按 4 位分组。经过一些快速的谷歌搜索，似乎有各种各样的加法器电路。
|
||||
- **位图**：你计算机的内存被组织成页（通常大小为 2 的 n 次方）。它需要跟踪每一页是否空闲。操作系统使用位图来完成这项工作，其中每个位对应一页，并且根据页面是空闲还是占用，值为 0 或 1。如果你有一个 9 位的字节，你需要除以 9 来在位图中找到你要查找的页面。除以 9 的速度比除以 8 慢，因为除以 2 的幂次方总是最快的。
|
||||
|
||||
我可能很糟糕地扭曲了其中一些解释：在这里，我非常超出了自己的知识领域。我们继续前进吧。
|
||||
|
||||
#### 原因 4：小字节大小很好
|
||||
|
||||
你可能会想：好吧，如果 8 位字节比 4 位字节更好，为什么不继续增加字节大小呢？我们可以有 16 位字节啊！
|
||||
|
||||
有几个保持字节大小较小的理由：
|
||||
|
||||
- 它是一种空间浪费 —— 字节是你可以寻址的最小单位，如果你的计算机存储了大量的 ASCII 文本（只需要 7 位），那么每个字符分配 12 或 16 个位相当浪费，而你可以使用 8 个位代替。
|
||||
- 随着字节变得越来越大，你的 CPU 需要变得更复杂。例如，你需要每个位线路一条总线线路。因此，我想简单总是更好。
|
||||
|
||||
我对 CPU 架构的理解非常薄弱，所以就说到这里吧。对我来说，“这是一种空间浪费” 的理由似乎相当有说服力。
|
||||
|
||||
#### 原因 5：兼容性
|
||||
|
||||
英特尔 8008（1972 年）是 8080（1974 年）的前身，8080 是第一款 x86 处理器 8086（1976 年）的前身。似乎 8080 和 8086 很受欢迎，这就是我们现代 x86 计算机的来源。
|
||||
|
||||
我认为这里有一个 “如果它好好的就不要动它” 的问题 - 我假设 8 位字节功能良好，因此英特尔看不到需要更改设计的必要性。如果你保持相同的 8 位字节，那么你可以重复使用更多指令集。
|
||||
|
||||
此外，80 年代左右我们开始出现像 TCP 这样的网络协议，它们使用 8 位字节（通常称为“<ruby>八位组<rt>octet</rt></ruby>”），如果你要实现网络协议，你可能希望使用 8 位字节。
|
||||
|
||||
#### 就这些！
|
||||
|
||||
在我看来，8 位字节的主要原因是：
|
||||
|
||||
- 很多早期的电脑公司都是美国的，美国使用最广泛的语言是英语
|
||||
- 这些人希望计算机擅长文本处理
|
||||
- 较小的字节大小通常更好
|
||||
- 7 位是你可以用来容纳所有英文字母和标点符号的最小尺寸
|
||||
- 8 比 7 更好（因为它是 2 的幂次方）
|
||||
- 一旦有得到成功应用的受欢迎的 8 位计算机，你希望保持相同的设计以实现兼容性。
|
||||
|
||||
有人指出 [这本 1962 年的书][20] 第 65 页谈到了 IBM 选择 8 位字节的原因，基本上说了相同的内容：
|
||||
|
||||
> 1. 其完整的 256 个字符的容量被认为足以满足绝大多数应用程序的需要。
|
||||
> 2. 在该容量范围内，单个字符由单个字节表示，因此任何特定记录的长度并不因该记录中字符而异。
|
||||
> 3. 8 位字节在存储空间上是相当经济的。
|
||||
> 4. 对于纯数字工作，一个十进制数字只需要 4 个比特表示，两个这样的 4 位字节可以打包成一个 8 位字节。尽管这种数字数据包装不是必需的，但为了提高速度和存储效率，它是一种常见做法。严格来说，4 位字节属于不同的代码，但与 4 位及 8 位方案相比，它们的简单性导致了更简单的机器设计和更清晰的寻址逻辑。
|
||||
> 5. 4 位和 8 位的字节大小，作为 2 的幂次方，允许计算机设计师利用二进制寻址和位级索引的强大功能（见第 4 章和第 5 章）。
|
||||
|
||||
总的来说，如果你在英语国家设计二进制计算机，选择 8 位字节似乎是一个非常自然的选择。
|
||||
|
||||
*（题图：MJ/3526a0d5-bee5-4678-8637-e96e9843b53c）*
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes/
|
||||
|
||||
作者：[Julia Evans][a]
|
||||
选题：[lkxed][b]
|
||||
译者：ChatGPT
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://jvns.ca/
|
||||
[b]: https://github.com/lkxed/
|
||||
[1]: https://social.jvns.ca/@b0rk/109976810279702728
|
||||
[2]: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
|
||||
[3]: https://en.wikipedia.org/wiki/IBM_System/360
|
||||
[4]: https://www.youtube.com/watch?v=9oOCrAePJMs&t=140s
|
||||
[5]: https://en.wikipedia.org/wiki/EBCDIC
|
||||
[6]: https://en.wikipedia.org/wiki/Intel_8008
|
||||
[7]: https://archive.computerhistory.org/resources/text/2009/102683240.05.02.acc.pdf
|
||||
[8]: https://archive.computerhistory.org/resources/access/text/2013/05/102702492-05-01-acc.pdf
|
||||
[9]: https://en.wikipedia.org/wiki/36-bit_computing
|
||||
[10]: https://en.wikipedia.org/wiki/Binary-coded_decimal
|
||||
[11]: https://commons.wikimedia.org/wiki/File:IBM-650-panel.jpg
|
||||
[12]: http://creativecommons.org/licenses/by-sa/3.0/
|
||||
[13]: https://upload.wikimedia.org/wikipedia/commons/a/ad/IBM-650-panel.jpg
|
||||
[14]: https://en.wikipedia.org/wiki/Nibble
|
||||
[15]: https://retrocomputing.stackexchange.com/questions/7937/last-computer-not-to-use-octets-8-bit-bytes
|
||||
[16]: https://poly.nomial.co.uk/
|
||||
[17]: https://www.falstad.com/circuit/circuitjs.html?ctz=CQAgjCAMB0l3BWcMBMcUHYMGZIA4UA2ATmIxAUgpABZsKBTAWjDACgwEknsUQ08tQQKgU2AdxA8+I6eAyEoEqb3mK8VMAqWSNakHsx9Iywxj6Ea-c0oBKUy-xpUWYGc-D9kcftCQo-URgEZRQERSMnKkiTSTDFLQjw62NlMBorRP5krNjwDP58fMztE04kdKsRFBQqoqoQyUcRVhl6tLdCwVaonXBO2s0Cwb6UPGEPXmiPPLHhIrne2Y9q8a6lcpAp9edo+r7tkW3c5WPtOj4TyQv9G5jlO5saMAibPOeIoppm9oAPEEU2C0-EBaFoThAAHoUGx-mA8FYgfNESgIFUrNDYVtCBBttg8LiUPR0VCYWhyD0Wp0slYACIASQAamTIORFqtuucQAzGTQ2OTaD9BN8Soo6Uy8PzWQ46oImI4aSB6QA5ZTy9EuVQjPLq3q6kQmAD21Beome0qQMHgkDIhHCYVEfCQ9BVbGNRHAiio5vIltg8Ft9stXg99B5MPdFK9tDAFqg-rggcIDui1i23KZfPd3WjPuoVoDCiDjv4gjDErYQA
|
||||
[18]: http://www.chebucto.ns.ca/~af380/z-80-h.htm
|
||||
[19]: https://en.wikipedia.org/wiki/Carry-lookahead_adder
|
||||
[20]: https://web.archive.org/web/20170403014651/http://archive.computerhistory.org/resources/text/IBM/Stretch/pdfs/Buchholz_102636426.pdf
|
||||
[0]: https://img.linux.net.cn/data/attachment/album/202305/30/115011gak5kqzsx3gfi2ud.jpg
|
||||
@ -1,220 +0,0 @@
|
||||
[#]: subject: "Some possible reasons for 8-bit bytes"
|
||||
[#]: via: "https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes/"
|
||||
[#]: author: "Julia Evans https://jvns.ca/"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
Some possible reasons for 8-bit bytes
|
||||
======
|
||||
|
||||
I’ve been working on a zine about how computers represent thing in binary, and one question I’ve gotten a few times is – why does the x86 architecture use 8-bit bytes? Why not some other size?
|
||||
|
||||
With any question like this, I think there are two options:
|
||||
|
||||
- It’s a historical accident, another size (like 4 or 6 or 16 bits) would work just as well
|
||||
- 8 bits is objectively the Best Option for some reason, even if history had played out differently we would still use 8-bit bytes
|
||||
- some mix of 1 & 2
|
||||
|
||||
I’m not super into computer history (I like to use computers a lot more than I like reading about them), but I am always curious if there’s an essential reason for why a computer thing is the way it is today, or whether it’s mostly a historical accident. So we’re going to talk about some computer history.
|
||||
|
||||
As an example of a historical accident: DNS has a `class` field which has 5 possible values (“internet”, “chaos”, “hesiod”, “none”, and “any”). To me that’s a clear example of a historical accident – I can’t imagine that we’d define the class field the same way if we could redesign DNS today without worrying about backwards compatibility. I’m not sure if we’d use a class field at all!
|
||||
|
||||
There aren’t any definitive answers in this post, but I asked [on Mastodon][1] and here are some potential reasons I found for the 8-bit byte. I think the answer is some combination of these reasons.
|
||||
|
||||
#### what’s the difference between a byte and a word?
|
||||
|
||||
First, this post talks about “bytes” and “words” a lot. What’s the difference between a byte and a word? My understanding is:
|
||||
|
||||
- the **byte size** is the smallest unit you can address. For example in a program on my machine `0x20aa87c68` might be the address of one byte, then `0x20aa87c69` is the address of the next byte.
|
||||
- The **word size** is some multiple of the byte size. I’ve been confused about this for years, and the Wikipedia definition is incredibly vague (“a word is the natural unit of data used by a particular processor design”). I originally thought that the word size was the same as your register size (64 bits on x86-64). But according to section 4.1 (“Fundamental Data Types”) of the [Intel architecture manual][2], on x86 a word is 16 bits even though the registers are 64 bits. So I’m confused – is a word on x86 16 bits or 64 bits? Can it mean both, depending on the context? What’s the deal?
|
||||
|
||||
Now let’s talk about some possible reasons that we use 8-bit bytes!
|
||||
|
||||
#### reason 1: to fit the English alphabet in 1 byte
|
||||
|
||||
[This Wikipedia article][3] says that the IBM System/360 introduced the 8-bit byte in 1964.
|
||||
|
||||
Here’s a [video interview with Fred Brooks (who managed the project)][4] talking about why. I’ve transcribed some of it here:
|
||||
|
||||
> … the six bit bytes [are] really better for scientific computing and the 8-bit byte ones are really better for commercial computing and each one can be made to work for the other.
|
||||
> So it came down to an executive decision and I decided for the 8-bit byte, Jerry’s proposal.
|
||||
>
|
||||
> ...
|
||||
>
|
||||
> My most important technical decision in my IBM career was to go with the 8-bit byte for the 360.
|
||||
> And on the basis of I believe character processing was going to become important as opposed to decimal digits.
|
||||
|
||||
It makes sense that an 8-bit byte would be better for text processing: 2^6 is 64, so 6 bits wouldn’t be enough for lowercase letters, uppercase letters, and symbols.
|
||||
|
||||
To go with the 8-bit byte, System/360 also introduced the [EBCDIC][5] encoding, which is an 8-bit character encoding.
|
||||
|
||||
It looks like the next important machine in 8-bit-byte history was the [Intel 8008][6], which was built to be used in a computer terminal (the Datapoint 2200). Terminals need to be able to represent letters as well as terminal control codes, so it makes sense for them to use an 8-bit byte. [This Datapoint 2200 manual from the Computer History Museum][7] says on page 7 that the Datapoint 2200 supported ASCII (7 bit) and EBCDIC (8 bit).
|
||||
|
||||
#### why was the 6-bit byte better for scientific computing?
|
||||
|
||||
I was curious about this comment that the 6-bit byte would be better for scientific computing. Here’s a quote from [this interview from Gene Amdahl][8]:
|
||||
|
||||
> I wanted to make it 24 and 48 instead of 32 and 64, on the basis that this
|
||||
> would have given me a more rational floating point system, because in floating
|
||||
> point, with the 32-bit word, you had to keep the exponent to just 8 bits for
|
||||
> exponent sign, and to make that reasonable in terms of numeric range it could
|
||||
> span, you had to adjust by 4 bits instead of by a single bit. And so it caused
|
||||
> you to lose some of the information more rapidly than you would with binary
|
||||
> shifting
|
||||
|
||||
I don’t understand this comment at all – why does the exponent have to be 8 bits if you use a 32-bit word size? Why couldn’t you use 9 bits or 10 bits if you wanted? But it’s all I could find in a quick search.
|
||||
|
||||
#### why did mainframes use 36 bits?
|
||||
|
||||
Also related to the 6-bit byte: a lot of mainframes used a 36-bit word size. Why? Someone pointed out that there’s a great explanation in the Wikipedia article on [36-bit computing][9]:
|
||||
|
||||
> Prior to the introduction of computers, the state of the art in precision
|
||||
> scientific and engineering calculation was the ten-digit, electrically powered,
|
||||
> mechanical calculator… These calculators had a column of keys for each digit,
|
||||
> and operators were trained to use all their fingers when entering numbers, so
|
||||
> while some specialized calculators had more columns, ten was a practical limit.
|
||||
>
|
||||
> Early binary computers aimed at the same market therefore often used a 36-bit
|
||||
> word length. This was long enough to represent positive and negative integers
|
||||
> to an accuracy of ten decimal digits (35 bits would have been the minimum)
|
||||
|
||||
So this 36 bit thing seems to based on the fact that log_2(20000000000) is 34.2. Huh.
|
||||
|
||||
My guess is that the reason for this is in the 50s, computers were extremely expensive. So if you wanted your computer to support ten decimal
|
||||
digits, you’d design so that it had exactly enough bits to do that, and no more.
|
||||
|
||||
Today computers are way faster and cheaper, so if you want to represent ten decimal digits for some reason you can just use 64 bits – wasting a little bit of space is usually no big deal.
|
||||
|
||||
Someone else mentioned that some of these machines with 36-bit word sizes let you choose a byte size – you could use 5 or 6 or 7 or 8-bit bytes, depending on the context.
|
||||
|
||||
#### reason 2: to work well with binary-coded decimal
|
||||
|
||||
In the 60s, there was a popular integer encoding called binary-coded decimal (or [BCD][10] for short) that encoded every decimal digit in 4 bits.
|
||||
|
||||
For example, if you wanted to encode the number 1234, in BCD that would be something like:
|
||||
|
||||
```
|
||||
0001 0010 0011 0100
|
||||
```
|
||||
|
||||
So if you want to be able to easily work with binary-coded decimal, your byte size should be a multiple of 4 bits, like 8 bits!
|
||||
|
||||
#### why was BCD popular?
|
||||
|
||||
This integer representation seemed really weird to me – why not just use binary, which is a much more efficient way to store integers? Efficiency was really important in early computers!
|
||||
|
||||
My best guess about why is that early computers didn’t have displays the same way we do now, so the contents of a byte were mapped directly to on/off lights.
|
||||
|
||||
Here’s a [picture from Wikipedia of an IBM 650 with some lights on its display][11] ([CC BY-SA 3.0][12]):
|
||||
|
||||
![][13]
|
||||
|
||||
So if you want people to be relatively able to easily read off a decimal number from its binary representation, this makes a lot more sense. I think today BCD is obsolete because we have displays and our computers can convert numbers represented in binary to decimal for us and display them.
|
||||
|
||||
Also, I wonder if BCD is where the term “nibble” for 4 bits comes from – in the context of BCD, you end up referring to half bytes a lot (because every digits is 4 bits). So it makes sense to have a word for “4 bits”, and people called 4 bits a nibble. Today “nibble” feels to me like an archaic term though – I’ve definitely never used it except as a fun fact (it’s such a fun word!). The Wikipedia article on [nibbles][14] supports this theory:
|
||||
|
||||
> The nibble is used to describe the amount of memory used to store a digit of
|
||||
> a number stored in packed decimal format (BCD) within an IBM mainframe.
|
||||
|
||||
Another reason someone mentioned for BCD was **financial calculations**. Today if you want to store a dollar amount, you’ll typically just use an integer amount of cents, and then divide by 100 if you want the dollar part. This is no big deal, division is fast. But apparently in the 70s dividing an integer represented in binary by 100 was very slow, so it was worth it to redesign how you represent your integers to avoid having to divide by 100.
|
||||
|
||||
Okay, enough about BCD.
|
||||
|
||||
#### reason 3: 8 is a power of 2?
|
||||
|
||||
A bunch of people said it’s important for a CPU’s byte size to be a power of 2. I can’t figure out whether this is true or not though, and I wasn’t satisfied with the explanation that “computers use binary so powers of 2 are good”. That seems very plausible but I wanted to dig deeper. And historically there have definitely been lots of machines that used byte sizes that weren’t powers of 2, for example (from [this retro computing stack exchange thread][15]):
|
||||
|
||||
- Cyber 180 mainframes used 6-bit bytes
|
||||
- the Univac 1100 / 2200 series used a 36-bit word size
|
||||
- the PDP-8 was a 12-bit machine
|
||||
|
||||
Some reasons I heard for why powers of 2 are good that I haven’t understood yet:
|
||||
|
||||
- every bit in a word needs a bus, and you want the number of buses to be a power of 2 (why?)
|
||||
- a lot of circuit logic is susceptible to divide-and-conquer techniques (I think I need an example to understand this)
|
||||
|
||||
Reasons that made more sense to me:
|
||||
|
||||
- it makes it easier to design **clock dividers** that can measure “8 bits were sent on this wire” that work based on halving – you can put 3 halving clock dividers in series. [Graham Sutherland][16] told me about this and made this really cool [simulator of clock dividers][17] showing what these clock dividers look like. That site (Falstad) also has a bunch of other example circuits and it seems like a really cool way to make circuit simulators.
|
||||
- if you have an instruction that zeroes out a specific bit in a byte, then if your byte size is 8 (2^3), you can use just 3 bits of your instruction to indicate which bit. x86 doesn’t seem to do this, but the [Z80’s bit testing instructions][18] do.
|
||||
- someone mentioned that some processors use [Carry-lookahead adders][19], and they work in groups of 4 bits. From some quick Googling it seems like there are a wide variety of adder circuits out there though.
|
||||
- **bitmaps**: Your computer’s memory is organized into pages (usually of size 2^n). It needs to keep track of whether every page is free or not. Operating systems use a bitmap to do this, where each bit corresponds to a page and is 0 or 1 depending on whether the page is free. If you had a 9-bit byte, you would need to divide by 9 to find the page you’re looking for in the bitmap. Dividing by 9 is slower than dividing by 8, because dividing by powers of 2 is always the fastest thing.
|
||||
|
||||
I probably mangled some of those explanations pretty badly: I’m pretty far out of my comfort zone here. Let’s move on.
|
||||
|
||||
#### reason 4: small byte sizes are good
|
||||
|
||||
You might be wondering – well, if 8-bit bytes were better than 4-bit bytes, why not keep increasing the byte size? We could have 16-bit bytes!
|
||||
|
||||
A couple of reasons to keep byte sizes small:
|
||||
|
||||
- It’s a waste of space – a byte is the minimum unit you can address, and if your computer is storing a lot of ASCII text (which only needs 7 bits), it would be a pretty big waste to dedicate 12 or 16 bits to each character when you could use 8 bits instead.
|
||||
- As bytes get bigger, your CPU needs to get more complex. For example you need one bus line per bit. So I guess simpler is better.
|
||||
|
||||
My understanding of CPU architecture is extremely shaky so I’ll leave it at that. The “it’s a waste of space” reason feels pretty compelling to me though.
|
||||
|
||||
#### reason 5: compatibility
|
||||
|
||||
The Intel 8008 (from 1972) was the precursor to the 8080 (from 1974), which was the precursor to the 8086 (from 1976) – the first x86 processor. It seems like the 8080 and the 8086 were really popular and that’s where we get our modern x86 computers.
|
||||
|
||||
I think there’s an “if it ain’t broke don’t fix it” thing going on here – I assume that 8-bit bytes were working well, so Intel saw no need to change the design. If you keep the same 8-bit byte, then you can reuse more of your instruction set.
|
||||
|
||||
Also around the 80s we start getting network protocols like TCP which use 8-bit bytes (usually called “octets”), and if you’re going to be implementing network protocols, you probably want to be using an 8-bit byte.
|
||||
|
||||
#### that’s all!
|
||||
|
||||
It seems to me like the main reasons for the 8-bit byte are:
|
||||
|
||||
- a lot of early computer companies were American, the most commonly used language in the US is English
|
||||
- those people wanted computers to be good at text processing
|
||||
- smaller byte sizes are in general better
|
||||
- 7 bits is the smallest size you can fit all English characters + punctuation in
|
||||
- 8 is a better number than 7 (because it’s a power of 2)
|
||||
- once you have popular 8-bit computers that are working well, you want to keep the same design for compatibility
|
||||
|
||||
Someone pointed out that [page 65 of this book from 1962][20] talking about IBM’s reasons to choose an 8-bit byte basically says the same thing:
|
||||
|
||||
> 1. Its full capacity of 256 characters was considered to be sufficient for the great majority of applications.
|
||||
> 2. Within the limits of this capacity, a single character is represented by a single byte, so that the length of any particular record is not dependent on the coincidence of characters in that record.
|
||||
> 3. 8-bit bytes are reasonably economical of storage space
|
||||
> 4. For purely numerical work, a decimal digit can be represented by only 4 bits, and two such 4-bit bytes can be packed in an 8-bit byte. Although such packing of numerical data is not essential, it is a common practice in order to increase speed and storage efficiency. Strictly speaking, 4-bit bytes belong to a different code, but the simplicity of the 4-and-8-bit scheme, as compared with a combination 4-and-6-bit scheme, for example, leads to simpler machine design and cleaner addressing logic.
|
||||
> 5. Byte sizes of 4 and 8 bits, being powers of 2, permit the computer designer to take advantage of powerful features of binary addressing and indexing to the bit level (see Chaps. 4 and 5 ) .
|
||||
|
||||
Overall this makes me feel like an 8-bit byte is a pretty natural choice if you’re designing a binary computer in an English-speaking country.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://jvns.ca/blog/2023/03/06/possible-reasons-8-bit-bytes/
|
||||
|
||||
作者：[Julia Evans][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://jvns.ca/
|
||||
[b]: https://github.com/lkxed/
|
||||
[1]: https://social.jvns.ca/@b0rk/109976810279702728
|
||||
[2]: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
|
||||
[3]: https://en.wikipedia.org/wiki/IBM_System/360
|
||||
[4]: https://www.youtube.com/watch?v=9oOCrAePJMs&t=140s
|
||||
[5]: https://en.wikipedia.org/wiki/EBCDIC
|
||||
[6]: https://en.wikipedia.org/wiki/Intel_8008
|
||||
[7]: https://archive.computerhistory.org/resources/text/2009/102683240.05.02.acc.pdf
|
||||
[8]: https://archive.computerhistory.org/resources/access/text/2013/05/102702492-05-01-acc.pdf
|
||||
[9]: https://en.wikipedia.org/wiki/36-bit_computing
|
||||
[10]: https://en.wikipedia.org/wiki/Binary-coded_decimal
|
||||
[11]: https://commons.wikimedia.org/wiki/File:IBM-650-panel.jpg
|
||||
[12]: http://creativecommons.org/licenses/by-sa/3.0/
|
||||
[13]: https://upload.wikimedia.org/wikipedia/commons/a/ad/IBM-650-panel.jpg
|
||||
[14]: https://en.wikipedia.org/wiki/Nibble
|
||||
[15]: https://retrocomputing.stackexchange.com/questions/7937/last-computer-not-to-use-octets-8-bit-bytes
|
||||
[16]: https://poly.nomial.co.uk/
|
||||
[17]: https://www.falstad.com/circuit/circuitjs.html?ctz=CQAgjCAMB0l3BWcMBMcUHYMGZIA4UA2ATmIxAUgpABZsKBTAWjDACgwEknsUQ08tQQKgU2AdxA8+I6eAyEoEqb3mK8VMAqWSNakHsx9Iywxj6Ea-c0oBKUy-xpUWYGc-D9kcftCQo-URgEZRQERSMnKkiTSTDFLQjw62NlMBorRP5krNjwDP58fMztE04kdKsRFBQqoqoQyUcRVhl6tLdCwVaonXBO2s0Cwb6UPGEPXmiPPLHhIrne2Y9q8a6lcpAp9edo+r7tkW3c5WPtOj4TyQv9G5jlO5saMAibPOeIoppm9oAPEEU2C0-EBaFoThAAHoUGx-mA8FYgfNESgIFUrNDYVtCBBttg8LiUPR0VCYWhyD0Wp0slYACIASQAamTIORFqtuucQAzGTQ2OTaD9BN8Soo6Uy8PzWQ46oImI4aSB6QA5ZTy9EuVQjPLq3q6kQmAD21Beome0qQMHgkDIhHCYVEfCQ9BVbGNRHAiio5vIltg8Ft9stXg99B5MPdFK9tDAFqg-rggcIDui1i23KZfPd3WjPuoVoDCiDjv4gjDErYQA
|
||||
[18]: http://www.chebucto.ns.ca/~af380/z-80-h.htm
|
||||
[19]: https://en.wikipedia.org/wiki/Carry-lookahead_adder
|
||||
[20]: https://web.archive.org/web/20170403014651/http://archive.computerhistory.org/resources/text/IBM/Stretch/pdfs/Buchholz_102636426.pdf
|
||||
Loading…
Reference in New Issue
Block a user