25

Related: What does 8-bit / 16-bit actually refer to?

I remember the "bit wars" of the late 1980s and early 1990s. The Genesis/Mega Drive and the PC Engine/Turbografx-16 were heavily marketed in the very early 90's as having twice as many "bits" (16) as the previous generation (Famicom/NES, Sega Master System, etc.). By 1993, Atari returned to the market with its monstrous cat-themed Atari Jaguar which they heavily touted as a 64-bit machine ("Do the math!"). This system was, as we remember, promptly pwned by the Nintendo 64 and Sony PlayStation before the decade was half up.

Starting around 2000, word size seems to have faded out of the world of gaming marketing and criticism. It became all about having wowie-zowie immersive 3D graphics, raw bit count be damned. I was looking at the 3DS on my shelf when I realized that I had entirely no idea what its word size was. I assume it is 32-bit or 64-bit based on my knowledge of contemporary PC's, but word size seems to have been completely absent in 3DS marketing and even discussion.

So, my question is, how high has word size actually gone in terms of gaming consoles? Was there ever a 128-bit console? 256? 512? 1024? How about a 2048-bit monstrosity? If I am dreaming of creating the world's first 4096-bit Mega Word Pwnage Rhinocerous9000 XL 2022, would that be a record or would I just be an also-ran in the lost Bit Wars?

To be clear, I'm not asking for a definition of or explanation of word size, nor am I asking why bit size is no longer prominent in console marketing. I'm asking a historical question about word size. Did bit size continue to grow behind the scenes (but was glossed over for marketing purposes) or are we literally still in the 32 and/or 64-bit console eras?

Improve this question
4

3 Answers 3

Reset to default
30

64-bit, really. All current-generation consoles are based on 64-bit processor architectures (AMD Zen x86-64 on the PS5 and Xbox; Nvidia Tegra AArch64 for the Nintendo Switch). Yes, they support SIMD instructions that can operate on up to 256 bits of data at once, but those are parallel operations on chunks of 64 bits or less (very often, 32-bit and even 16-bit floats).

As mentioned in pinckerman's answer, manufacturers around the year 2000 tried marketing their new systems as "128-bit" because the 90s encouraged consumers to associate the "bitness" of a console with generational improvements and they wanted to one-up the "64-bit" generation... but thankfully they learned the futility of that and didn't take it any further.

Fundamentally, in gaming and everywhere else, "more bits" is dead. There are a few niche scientific applications where extended floating-point precision is needed, and some applications like cryptography that deal with integers thousands of bits long, but for 99.9% of everything 64 bits is plenty — and for the rest, you can always do the operations in software, at a speed penalty. The push instead is for more throughput, more parallelism, and more power efficiency.

Footnote: actually, if you want to be a stickler, many x86 processors since the 1980s, and essentially 100% of them since the mid-90s, have hardware support 80-bit floating-point numbers. For various reasons, this has not led anyone to call anything with an Intel-compatible FPU an "80-bit machine".

Improve this answer
9
  • 7
    To expand on your third paragraph, especially for readers who might not have a programming background: the reason why we might want to add "more bits" is simply so that we can perform computations on bigger numbers without needing to break those computations into smaller steps. For example (assuming unsigned integers), an 8-bit processor can only perform arithmetic on numbers up to 255 without a performance penalty, whereas a 16-bit CPU can go up to 65,535. 32 bits gets us to over 4 billion, and 64 bits all the way to 18.4 sextillion.
    – NobodyNada
    Dec 2, 2021 at 2:59
  • 8
    It's very rare for any program to need to work with a number that big, so there's no point in making your entire processor twice as complicated to support it. It's a much better use of your limited silicon to build a processor optimized for handling more numbers rather than bigger numbers.
    – NobodyNada
    Dec 2, 2021 at 3:00
  • 1
    @NobodyNada that's one definition of CPU bit-ness. Other common ones are pointer size (common on computers) and the largest SIMD operand size (marketing for PS2 and others)
    – ojs
    Dec 2, 2021 at 9:39
  • @ojs "that's one definition of CPU bit-ness. Other common ones are pointer size [...]" Nearly all "8-bit" systems (including the NES and Game Boy) have 16-bit pointers. However, a pointer size bigger than the "true" word size is a huge pain to program for and was only done out of unavoidable necessity, so I'm not aware of any larger architectures where the pointer size did not match the "real" word size (16-bit segmentation/"far pointer" tricks notwithstanding).
    – NobodyNada
    Dec 2, 2021 at 20:45
  • @NobodyNada how would you classify Pentium MMX and later that could handle 64-bit numbers natively? Or for more niche applications, TMS320C55x series that had ALU with 16-bit operands and 32-bit result register and 24-bit pointers with nice hardware support?
    – ojs
    Dec 2, 2021 at 21:34
19

The 6th generation of consoles is known as 128-bit era.
The Dreamcast and the PlayStation 2 were the last systems to use the term "128-bit" in their marketing to describe their capability.

The PlayStation 2's CPU (known as the "128-bit Emotion Engine") has a 64-bit core with a 32-bit FPU coupled to two 128 bit Vector Units. The PS2 also has an internal 10 Channel DMA Bus which is fully 128 bits wide.

The Dreamcast has a 64-bit double-precision superscalar SuperH-4 RISC Central processing unit core with a 32-bit integer unit using 16-bit fixed-length instructions, a 64-bit data bus allowing a variable width of either 8, 16, 32 or 64-bits, and a 128-bit floating-point bus.

Increasing the number of bits for a component wouldn't really help you out and would probably just make it harder to design your console. The PS2's CPU was really just capable of doing four 32-bit calculations at once, so again they were marketing it as something that wasn't really true (in a way people would expect). Video games don't really need to go above 64 bits for the current era.

So I really doubt any consoles were ever advertized as 256-bit (or above), although modern x86-based consoles with CPUs supporting AVX do have 256-bit SIMD, and 256-bit data paths between load/store units and cache. (AMD Jaguar handles 256-bit AVX instructions internally as 2x 128-bit operations, but later CPUs like Zen2, and Intel Haswell, truly have 256-bit data paths and execution units.)

And I doubt any consoles ever existed with what CPU architects would really describe as 128-bit CPUs; that was only ever marketing based on SIMD width.

Even modern number-crunching servers don't use the full 64 bits of physical or virtual addresses that are possible with x86-64 and AArch64, although on paper RISC-V defines a version of that ISA with 128-bit addresses and integer registers. If you define bitness as pointer width / address-space size, and/or integer register width, 64-bit is huge.

For throwing more data around with each instruction, modern architectures use separate SIMD registers, not wider integer registers.

Improve this answer
7
  • 5
    It's...not really justifiable to describe a processor with 128-bit SIMD as a 128-bit processor -- maybe an overzealous marketing department did that, but it certainly doesn't align with any conventional definition of word size. Recent Intel CPUs support 512-bit SIMD, yet are still described as 64-bit processors, because the rest of the processor is only designed to operate on values up to 64 bits.
    – NobodyNada
    Dec 2, 2021 at 2:33
  • 1
    So I really doubt 256-bit (or above) consoles ever existed. - if you follow that definition, then yes, they do. Modern x86-based consoles use CPUs with AVX / AVX2 enabled, i.e. 256-bit (32-byte) vectors of 8x float or 4x double. (Or integers of 1, 2, 4, 8-byte element size, e.g. vpaddb ymm0, ymm1, [rdi]; see Intel's manual entry for paddb/w/d/q)
    – Peter Cordes
    Dec 2, 2021 at 11:42
  • 1
    Of course if you want to talk about "at once", instruction-level parallelism comes into play (how many independent instructions per clock cycle, e.g. 2x 256-bit FMA on Intel since Haswell, AMD since Zen2), and bitness doesn't capture that. (Which is probably why marketing departments stopped being silly, as hobbs suggested.)
    – Peter Cordes
    Dec 2, 2021 at 11:45
  • 1
    But neither machine you talked about has even 128-bit word size. It would make much more sense to say "I really doubt 128-bit word-size (or above) consoles ever existed"; your phrasing implies you're accepting those claims of being 128-bit. (And BTW, "word size" is a pretty nebulous term even today when register width is usually the same as addr width. Modern x86 for example doesn't really have a single natural size, as I argued in this SO answer).
    – Peter Cordes
    Dec 2, 2021 at 22:16
  • 1
    Ok, submitted a suggested edit. The question asked "Was there ever a 128-bit console?" and the real answer is "no, except for marketing claims". Even in big-iron servers and high-performance computing clusters, 64-bit is still more than enough. For example, a recent extension to x86-64 (PML5 found in Intel since Ice Lake) allows virtual addresses up to 57 bit, up from 48-bit. Physical addresses are still 52-bit, limited by page-table format. (Why in x86-64 the virtual address are 4 bits shorter than physical, 48 vs 52?). IDK about AArch64 / PowerPC
    – Peter Cordes
    Dec 3, 2021 at 0:09
3

The Nuon hybrid DVD player / console had a VLIW CPU focused on 128bit SIMD instructions to get the necessary power. On the other hand, its short lifespan and handful of games meant that it never really had much opportunity to show its skills off beyond Jeff Minter’s creations.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .