1
$\begingroup$

Will the IBM PC ever move towards 128 bit architecture? Is that even possible or is the 64 bit architecture we have now the ceiling?

$\endgroup$
1

2 Answers 2

6
$\begingroup$

Will the IBM PC ever move towards 128 bit architecture? Is that even possible or is the 64 bit architecture we have now the ceiling?

Those are really two completely separate questions, so I am going to answer them separately.

Is that even possible or is the 64 bit architecture we have now the ceiling?

That really depends on how you define "IBM PC". The IBM PC is a 16 bit architecture, and has been dead since the early 1990s. So, technically speaking, no, you can't have a 128 bit IBM PC, because the IBM PC is 16 bit, and if it were 128 bit, then it wouldn't be an IBM PC anymore.

However, there is nothing stopping anyone from doing what Intel did when they introduced the IA-32 architecture by extending the x86 architecture from 16 bit to 32 bit, or what AMD did when they introduced the AMD64 architecture by extending the IA-32 architecture from 32 bit to 64 bit.

There is also nothing stopping anybody from introducing a 65 bit or 96 bit or 512 bit architecture.

So, yes, it is definitely possible to design an architecture that is a careful extension of the current mainstream AMD64-based "PC successor" architecture. It wouldn't be an IBM PC, though, just like what we had since the 1990s weren't IBM PCs either.

Will the IBM PC ever move towards 128 bit architecture?

"ever" is a really long time, but I doubt it.

The current (and all currently known future planned) implementations of the AMD64 architecture, regardless of whether they are being designed and manufactured by Intel, by AMD, or someone else, are limited to a virtual address space of 48 bit and a physical address space of 48 bit. This means that the limit for both virtual memory and physical memory is 256 TiByte. However, there are currently no known or planned motherboards or chipsets that support even close to that amount of memory. (Also, I believe that while current CPUs support 48 bit physical addresses, they typically do not actually have 48 address pins, so the actual maximum is even lower.)

The virtual address space can theoretically be extended up to the full amount of 64 bit. The physical address space is limited by the page table format to 52 bit (4 PiByte).

So, a more conservative first step before we move to 128 bit would be to redesign the page table format such that the full 64 bit can be used.

At the moment, the 48 bit limitation does not seem to be a problem, even remotely. But even if we assume that we are going to run out of 48 bit address space tomorrow, and that address space requirements will grow similar to Moore's Law, doubling every 1.5–2.5 years, it will take another 20–40 years until we run out of 64 bit address space.

The largest supercomputer in the world, Fugaku consists of 158976 compute nodes. Each node has 32 GiByte of RAM, for a total of 4.85 PiByte. Each group of 16 nodes has a 1.6 TByte SSD as level 1 storage, for a total of 15.53 PByte. Plus, there is a shared 150 PByte cluster filesystem (Lustre) for the whole cluster.

So, the total amount of storage of the largest computer in the world currently is about 171.4 PByte or 152.2 PiByte, which could be byte-addressed with 57.24 bits, and even if you want to address every single individual bit, you would only need 60.24 bits. So, even if we assume that all supercomputers are this big, 64 bit would still be enough to address every single individual bit of the total combined storage of the TOP 10 supercomputers in the world. But note that this is the total sum of storage (not just RAM, but hard disk and network filesystem) in the entire cluster (not just each node), and that we normally address bytes, not bits.

In reality, there is not a single OS kernel running on the entire cluster that needs to address all that storage, each of the 158976 nodes is running its own OS kernel, and only needs to address its 32 GiByte of local RAM.

There is a general trend in the industry, where computers aren't getting "bigger" but are instead getting "more". For example, the total amount of RAM in my home has grown by a factor of 200 over the last 20 years, but 20 years ago, it was all in my desktop, and now it is distributed among my two laptops, two phones, two tablets, router, and NAS, so even my "largest" computer only has about 50 times as much RAM as my old desktop. (I am cheating a bit because I also use cloud services heavily, but those are actually also not a big computer but hundreds of thousands of medium sized ones, each with their own individual address space.)

The clock frequency per core in the current top supercomputers is only about 10 times that from 2000. The memory per node is about 10–50 times that from 2000. (For example, the top supercomputer in 2000, ASCI White, had 12 GiByte per node, Fugaku has 32 GiByte per node, so only less than 3 times the amount of RAM.) But the number of cores is about 1000–10000 times that of 2000! Each Fugaku node has 48 cores, meaning Fugaku has 7.6 million custom ARM64 cores. The supercomputer with the most number of cores in the TOP 10 supercomputers of November, 2000 has 9632 cores (interestingly, that one is not the fastest), and there are even two supercomputers in the TOP 10 from November, 2000 that only have 100 and 112 cores (and again, interestingly, they are not the slowest).

So, in 20 years, the physical address space requirements for the world's top supercomputer have only grown by less than 1.5 bit from 33.6 bit for 12 GiByte to 35 bit for 32 GiByte.

The thing is, humans are very bad at understanding exponential growth and tend to severely underestimate it. When Intel moved from 8 bit to 16 bit, they didn't double the address space, they increased it by a factor of 256. When Intel moved from 16 bit to 32 bit, they didn't double the address space, they increased it by a factor of 65536. When AMD moved from 32 bit to 64 bit, they didn't double the address space, they increased it by a factor of over 4 billion.

So, I personally doubt that we will ever see a 128 bit architecture. We might see more than 64 bit someday, but I believe it is more likely to be an 80 bit or 96 bit architecture than 128 bit.

Note that this does not mean that there might not be "labels" that need more than 64 bit. For example, IPv6 addresses are 128 bit. The IBM AS/400 (which still exists to this day as IBM i, after many name changes) had 128 bit object labels even back in the 1980s, but these contain not just a memory address but also type information, ownership information, access rights, bookkeeping data, etc. The actual CPU architecture, however, was never 128 bit. It was originally a custom 48 bit CISC architecture specially designed for the AS/400, which was later replaced with a slightly extended 64 bit PowerPC architecture and has now been merged into the POWER architecture.

While I believe it is possible that we might see bigger-than-64 bit architectures in the future, I seriously doubt that we will see another big change to the "PC successor" architecture. All current mainstream Operating Systems are highly portable (for example, Linux runs on a dozen architectures or more, both macOS and Windows NT run on AMD64 and ARM64, and have run on even more architectures in the past, e.g. macOS on PowerPC and m68k, Windows NT on Sparc, PowerPC, MIPS, Alpha, and i860). Which means that Operating Systems aren't really tightly tied to a specific architecture anymore. And the rise of platforms such as Java and .NET, the rise of high-level languages like, well, pretty much every language except C, C++, and (maybe) Rust, the rise of Web Applications and the Cloud mean that switching architectures is rather painless. (And actually, a lot of modern C and C++ code tends to be rather high-level and mostly platform-independent as well.)

Even for native code that we have lost the source for, modern emulation and re-engineering technologies make it possible to move them to a new architecture. Heck, I am writing this very answer from an ARM64 laptop that executes native AMD64 code in emulation almost as fast, sometimes even faster than my twice as expensive AMD64 laptop!

So, it simply does not make sense to keep piling band-aid after band-aid on a 1970s architecture, when we could just as easily design a 2030s architecture instead.

$\endgroup$
4
  • $\begingroup$ So basically we need to use the 64 bit architecture to its fullest capabilities before we are going to want to move to something bigger. $\endgroup$
    – Neil Meyer
    Aug 21, 2021 at 13:26
  • $\begingroup$ We don't need to, but it just doesn't make sense. We aren't even using half of the bits AMD added 22(!!!) years ago. Why would we add the complexity if we aren't using it? I think the "PC lineage" architecture will never be significantly changed again. All modern mainstream OSs are highly portable (Linux runs on about a dozen or more architectures, macOS is currently running an AMD64 and ARM64 and has run on x86, PowerPC (32 and 64 bit) and m68k in the past, Windows NT is currently running on AMD64 and ARM64 and has run on x86, PPC, Sparc, MIPS, and Alpha in the past), it is more likely, we $\endgroup$ Aug 21, 2021 at 13:32
  • $\begingroup$ … will switch to a new architecture. $\endgroup$ Aug 21, 2021 at 13:32
  • $\begingroup$ Since this is all a few years away, we’ll have plenty of time to figure out if we want substantial other changes in our architectures. $\endgroup$
    – gnasher729
    Aug 22, 2021 at 13:47
4
$\begingroup$

My CPU has 128 bit registers. Yours probably does too. The overwhelmingly most common use is to store lots of smaller values (e.g. two 64-bit values or four 32-bit values).

My CPU also does not support a 64-bit physical address space (more like 48 bits, IIRC). It does support a full 64-bit virtual address space, although half of that is reserved for the operating system.

Forever is a long time, however for the foreseeable future (say, the next few decades at least), it doesn't look like 128 bit addressing of memory will of any practical benefit.

64-bit values seem to be a "sweet spot" for a lot of real-world-sized values. Take money as an example. About 54 bits is enough to store the amount of M3 money in the world measured in Japanese Yen.

Or take time. At the moment, it seems impractical for consumer hardware to measure times smaller than a nanosecond, because light travels about 300mm (11.8in) in one nanosecond, and this roughly the scale of a consumer device. A 32-bit integer can record measurements of about 4.3 seconds in nanoseconds, but a 64-bit integer can record measurements of over 500 years, which is probably a reasonable upper bound on how long a computer can be left on without rebooting.

Nonetheless, 128 bit arithmetic, both integer and floating point (most logic operations are already supported), are probably coming in a few iterations. Internal busses are already wide enough to support the 128-bit and 256-bit registers that are common today.

While 128-bit integer operations are already quite fast on modern superscalar CPUs, there are applications that would benefit from 128-bit floating point, even if only for use in intermediate values or for evaluating special functions to 64-bit precision.

$\endgroup$
3
  • 1
    $\begingroup$ What’s M3? ---- $\endgroup$ Aug 21, 2021 at 7:17
  • 1
    $\begingroup$ M3 is the broadest and loosest definition of what constitutes "money", so it is the one which will generally produce the largest amounts, and thus the largest numbers. Hence it is used in this answer as a worst-case assumption: even by the loosest, broadest definition of "money", you can store all the money in the entire world in 54 bits. $\endgroup$ Aug 21, 2021 at 7:21
  • $\begingroup$ Yes, that. I picked the biggest number I could find and used the lowest-numeric-value internationally-used currency I could think of to get the largest number I could. $\endgroup$
    – Pseudonym
    Aug 21, 2021 at 7:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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