21

Though today various power-of-2 word sizes seems to be the norm, back in the 50-60s multiple-of-6 word sizes was more popular and was required by Department of Defense(DOD) in particular. 36-bit UNISYS ClearPath IX series survive even today.

With many of the pros mentioned in "What was the rationale behind 36 bit computer architectures?", was there some particular design theory or constraint that made a 32-bit word size attractive for IBM to migrate to?

BTW: I don't think 7-bit ASCII justified 8 bit bytes. 36-bit words pack better than 32-bit words. EBCDIC is a better rationale, but it won't save much effort to emulate or migrate code from 6-bit BCDIC to 8-bit EBCDIC than to contemporary, IBM-driven, 7-bit ASCII.

2
  • 18
    DIdn't we settle this some time ago in this forum? The reason for the 8-bit byte, which then gives rise to the 32-bit word, is System/360. And the reason S/360 has 8-bit bytes was given by Amdahl, Brooks, and Blaauw. Apr 20 at 11:35
  • 3
    Re "With many of the pros mentioned in ...", hmmm, The top answer says power of 2s are better these days. The second answer list multiples of 6 and 9 as good because of common-at-the-time protocols which are no longer used.
    – ikegami
    Apr 20 at 23:22
38

there some particular design theory or constraint that made a 32-bit word size attractive for IBM to migrate to?

It all comes down to the most basic data type, addressing constrains and, less important, reuse of existing memory technology.

  • The byte size had to be a multiple of 4, as needed to accommodate BCD numbers without wasting space.
  • So 8 was chosen as byte size it can hold a text character or two BCD digits with least possible waste.
  • The Machine introduced not only the idea of 8 bit bytes, but also byte addressing as basic address granularity (*1)
  • As a result word length had to be a power of 2 of the number of bytes within(*2).
  • Words (binary arithmetic) within the /360 were primarily meant for address handling
  • The first multiple of 1 is two, so 16 bits would have made sense as word/register size
  • Except, the /360 design called for more addressable memory than just 64 KiB (*3)
  • The next larger word size would be 32 bits - which in turn was quite future proof (*4).

Bottom Line, 32 bit is the first logic choice to satisfy all of the above: a word size that allows byte addressing with a byte size that can hold an integer amount of BCD symbols without waste (*5).

As a side effect, 32 bits also allowed the reuse of existing 36-bit core module design as 32 data bits plus 4-bit ECC.

BTW: I don't think 7-bit ASCII justified 8 bit bytes.

At that time computers were not about text processing - especially not a ISA with a major use in replacing tabulating machinery. Here text was used to print table headers and item names, not much more. Text storage was of much lesser concern. It was about "unit price ✕ units sold ✕ tax rate" - all done in BCD. That's where the market was and the dollars would be spent, not fancy university projects or fantasy stuff like word processing. :))


*1 - Before that, basically all machines had word addressing; byte manipulation was done using extraction instruction - or rather complicated combined word and bit(field) addressing.

*2 - While power of two is not important for the number of bits within bytes or words, it is essential for addressing - at least with machines using binary addressing. So if a byte within a word has to be addressable without special means, the number of bytes in a word must be power of two.

*3 - Only the low end -30 (and the extremely reduced -20) maxed out at 64 KiB. The -40 was expandable to 256 KiB, while the -50 already started at 64 KiB and went up to 512 KiB.

*4 - It was so gigantic, that they decided to use only 24 bits thereof - and it took more than 10 years until the first /370 could be ordered with 16 MiB - and more than 25 years before 32 bits were reached.

*5 - The next bigger size would be 12-bit bytes and 48-bit words, which of course would mean that character storage would be quite wasteful. And no, putting a 6-bit character into a 12-bit byte would not help, as it would take away the ability to address characters: they would need packing and unpacking again. Not to mention that 6 bits was already seen as insufficient.

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka
    Apr 21 at 15:33
6

One small reason is that you can access memory as a bit array without needing to divide (or do a modulo). Just use the bottom N bits for the byte or word or data cache line position or shift, and the rest of the bits left over as a memory address offset. Which can be done in hardware for free if needed.

2
  • There are some tricks that can be used to hold bit arrays that don't care about the word size being a power of two. For example, on a 36-bit machine with 9-bit bytes, one could store 9 N-bit arrays by having each array use one bit from N bytes. One could also e.g. store a 2304-bit array by using the bottom 8 bits of the index to select one of 256 bytes and the top 4 bits to select a bit within that byte. Using a power-of-two word size may be convenient, but approaches like I described are often useful even on microprocessors with power-of-two word sizes.
    – supercat
    Apr 22 at 16:08
  • Good tricks for large single bit arrays. Maybe not so efficient for smaller arrays, or arrays of variable length bit encodings (Huffman, et.al.) on small memory systems.
    – hotpaw2
    Apr 22 at 21:08
5

Worthy of mention is the rise of the microprocessor- notably the 4004 which was designed for mostly numerical operation in calculators. Whether the step to 8 bit architecture was inevitable is open to debate, but once memory ICs started being produced in 8-bit forms, it would be difficult to justify anything other than 16-bit as the next step. Looking at x86 architecture it’s apparent that the move to 32-bit wasn’t done in one leap, but via 24-bit chicanery.

6
  • 3
    The 8086 used 20 bits (16+16, 12 bits overlap, 1MB address space, leading to the famous 640kB RAM). IIRC the 24 bits is only used in the 80286.
    – MSalters
    Apr 20 at 12:49
  • 2
    The 8-bit RAM chips were (by and large, there may have been exceptions) a later invention to meet CPU needs, not the other way around. I remember installing 4164 (64k x 1 bit) and 41256 (256k x 1 bit) chips in IBM PCs, etc. It makes little difference whether you put in 8 256k x 1 or 8 32k x 8 or 16 16k x 16. I mean, it does change the design somewhat, but practically speaking, it was quite a while before we got to the modern era of individual (or still sometimes pairs) of memory modules instead of a whole bunch of individual chips. Apr 20 at 15:24
  • 8 bit wide RAM chips were first do enable a working (minimal) system with a single chip instead of 8 (6810) , while later (and in addition) being a way to use larger integration in systems with limited address size (62256).
    – Raffzahn
    Apr 20 at 22:04
  • 1
    x86 has never been able to load 3 bytes (24 bits) from memory in one instruction. (Until AVX-512BW masked loads, if you count a 16-byte load with only 3 unmasked bytes as a 3-byte load.) 20 and 24 bits are the sizes of physical address space on 8086 and 286 respectively, but it's not normal to store pointers in that format. (Always in 16:16 seg:off format because that's the only way you can actually dereference them. Or just the 16-bit offset for a known segment, or in 386, flat memory model and just store a 32-bit offset as a pointer.) Apr 21 at 18:17
  • 2
    It might also be worthy of mention that DEC moved from a 36 bit architecture with the PDP-10 to a 16 bit architecture with the PDP-11, following the move by IBM from the 7090 to the 360. DEC further moved to a 32 bit architecture with the VAX. Apr 22 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.