For mainstream computing what are the practical advantages of 64-bit register size CPUs given the needs of today and the near future? [closed]

Question

I understand one of the limitations of 32-bit processors is the inability to easily address more than 4GiB of RAM, which is a present day need even for mainstream computing on phones, tablets and laptops.

What are some other mainstream computing advantages of a 64-bit register size architecture as opposed to a 48-bit register size architecture?

Please cite relevant sources or provide detailed reasoning in your answers. Number of bits which are powers of two are better does not provide a technical justification.

Of course if price were not a consideration then the more bits the better, also we obviously cannot predict distant future needs.

A wider bus may be able to move data more quickly but the bus size doesn't always have to match the register size does it? Also a CPU with more transistors and more lines may be forced to run at slightly slower clock rate due to physical limitations perhaps?

With 48 bits you can address 256TiB of RAM: plenty of space to be useful for at least the next few decades. It seems that, generally, 32 bit numbers are already plenty large for most integer and decimal calculations for mainstream programming, making 64 bit seem wasteful. 64 bit applications end up consuming more RAM and the processor itself ends up with a lot of wasted transistors in the ALU, control unit and bus for bits that simply aren't needed. All that stuff takes up extra silicon space which could be used to simply make processors smaller and cheaper or could be put to better use in the form of caches or additional cores.

Answer 1

With 48bits you can address 256TiB of RAM, plenty of space to be useful

Its not about address space (*).

In fact most 64-bit desktop processors have a 48-bit address bus. There is little point going larger than that, you are correct.

It seems that generally 32bit numbers are already plenty large for most integer and decimal calculations

Many, but by no means all, and probably not most. Lots of calculations (even on 32-bit CPUs) end up using 64-bit calculations

The simplest example of this is the Y2k38 bug that will come to bite any system that uses a 32-bit Unix timestamp within the next 20 years.

Many floating point numbers are double precision (64-bit) because a single precision float gives very limited range.

64-bit processors can also still perform 32-bit calculations, and in fact having 64-bit caches allows twice as many 32-bit values to be stored in cache potentially speeding up the performance by reduction of memory operations (cache misses)

Modern 64-bit processors supporting advanced SIMD-style instructions can also perform multiple 32-bit operations simultaneously, so even 32-bit calculations can benefit.

So why did processor designers chose to make the jump to 64bit so soon?

Where the 64-bit comes in is the data bus. We tend to like working in power of two multiples of our base value - in computers this is typically an 8-bit byte. So powers of two would be 8-bit (1 x 8bit), 16-bit (2 x 8bit), 32-bit (4 x 8bit) as you expect. The next logical step up therefore is 64-bit (8 x 8bit).

48-bit data buses would be a non-power-of-two number of bytes, which makes addressing operations more interesting as the data ceases to be aligned on nice power of two multiple boundaries. It's not impossible to do, its just fairly uncommon.

---

(*) Well, it is a bit.

Answer 2

While there are a handful of exceptions, the computing industry has largely standardized on 8-bit bytes*.

It is highly desirable to have the word size be a power of two multiple of the byte size. Not doing so would lead to some extremely messy address translation when the bus system needs to translate byte addresses to word addresses.

It is also highly desirable to be able to manipulate memory addresses in a single data word, especially on a modern highly-pipelined CPU.

It is also highly desirable to have backwards compatibility, which means a 32-bit mode. Adding support to your system for dealing with "half words" is relatively easy, adding support for dealing with "two thirds words" would be much messier.

Put these factors together and the most logical way to increase the memory address space beyond the 32-bit limit is to expand the data word size to 64 bits. Even if you don't immediately plan to use all of those bits for memory addressing (many 64-bit systems have a less than 64 bit memory address space).

* For the purposes of this post "byte" is used to refer to the smallest unit of data the processor can address, and "word" is used to refer to the widest data type that the main integer data-paths can deal with as a single unit.

Answer 3

You think it's wasteful, but saving in one place usually means wasting in another.

Saving few register cells on word size makes you waste CPU cycles on handling misaligned values. There would certainly be no issues running new, all-48bit programs, but trying to run old 32bit program on a 48bit CPU would be a nightmare. All the transistors you could have saved would most likely be paid back with interest in the form of a dedicated 32-bit handling/translating units. The alternative would be breaking backwards compatibility, aka "the CPU nobody has any use for".

That's very similar to what killed Intel's 64-bit Itanium: as a brand-new architecture it couldn't run legacy 32-bit code as fast as AMD's (comparatively) crude stretch of x86 to twice the word size. Nobody stayed around to see if Intel's brave new world would eventually materialize - the costs of transition scared everyone away. AMD, on the other hand, brought "more of the good old stuff" and look at us: 16 years later we still have remains of 32bit code floating around and our 64bit CPUs run it faster than 32bit CPUs ever could.

It's not 80's anymore. Ram and register space is not at premium now, so we no longer aim for "as little as possible". We shot at "as much as practical" instead. 64 bits was the most practical: as Tom said we already were running some 64bit precision on 32 bit CPUs, but IMHO the main selling point was effortless handling of legacy.

In x86 market, heritage tracing all the way back to IBM XT is a force to be reckoned with. And since one architecture had 64 of something, nobody could sell having less of the thing. That's marketing. Clients don't understand what the thing is, they just know that more is better.

Answer 4

I started working with big computers on a computer that had a 60-bit word width addressed per word, used 6-bit units as characters (10 to a word) though there were several 12-bit characters (like lowercase letters). Addresses and address registers were 18 bit. This was a system primarily for number crunching: text processing was distinctly awkward due to memory not being addressable by character.

So what is wrong with that kind of setup today? Today's data, for better or worse, is almost universally exchanged in byte-sized quantities. Byte-sized quantities are addressed with binary addresses and are organized in sectors/chunks/units that have a power-of-2 byte size. While there are special instructions addressing bits in very limited contexts, the standard is for instructions to address bytes, including instructions that only work with whole words. Even on CPUs with strict alignment requirements (though the x86 architecture members are pretty lax here), memory addresses uniformly are byte addresses (I remember one TI graphics oriented processor where the basic addressable unit was actually a single bit, but that already was an oddity at its time)

Files have byte sizes and everything goes by power-of-2, with the actual data bus transfers being a multiple of the CPU word width. Fitting 48-bit words into that world would be nightmarish since instead of just splitting your address into a part addressing a larger bus width and a part addressing a byte, you'd have to perform an actual division by 6 for figuring out address and offset in larger word widths (you cannot really expect to get memory devices specifically catering to your word width choices).

In short: in a world of standardized data representations and character sets and stock peripheral units and interfaces, using word widths other than powers of 2 would be vastly more prohibitive than at the times when "computer mice" would refer to rodents burrowing in punchcard boxes, a significant danger to longtime data storage.

Answer 5

N64 software developers found that 64-bit ISA code performed better on real code than compiling for the 32-bit MIPS ISA, because you could move more data and store more bits in fast register space with less instructions.

The 64-bit ISA was far more backwards compatible with existing 32-bit code than some other non-power-of 2 register and data size, which made programming and porting libraries easier.

And the R4200 MIPS processor chip was only a few percent larger in die size (IIRC, less than 10%) to support the 64-bit rather than just the 32-bit MIPS ISA. Win win.

Answer 6

Another reason is software. Porting an operating system, or any application that manages memory in complicated ways, to a different pointer size is hard work. For an operating system, all the device drivers tend to have to be revised too.

Software companies prefer not to do this work too often; some of them started porting from 32-bit to 64-bit in the 1990s and regard 32-bit as obsolete as of 2019; others are only now starting. It depends on the markets they serve.

If all of the vendors who historically introduced 64-bit architectures between 1992 (DEC Alpha) and 2005 (Intel) had picked 48-bit instead, then it might have been established. However, by now it would have been getting too close to its limits for comfort in the future, and 64-bit would be starting to come it.

If there had been both 64-bit and 48-bit architectures offered in the 1990s, the far-sighted software companies would have ignored 48-bit, and concentrated on the 64-bit architectures. The companies who'd gone for 48-bit would now be starting a second porting cycle and the first would have involved the complexities of a non-power-of-two pointer size, which they'd be seriously regretting.

The hardware vendors could see the outlines of this scenario in the 1990s, and decided to go for the approach that would last longer.

Answer 7

Not all chip designers did jump straight to 64bit from 32bit. IBM’s S/38 and later AS/400 series of servers (now IBM System i) used 48-bit CISC chips from the late 1970s, before eventually changing over to 64-bit in the mid 90s.

Answer 8

Actually, if we are talking about AMD's jump to 64bit with the x86-64, which literally revolutionize the platform, it was basically to make Athlon CPUs more powerful than intel chips, thereby giving them a competitive advantage in the marketplace, as Intel was kicking their butts. This forced intel, the industry leader, to become a follower. However, this had to be done in coordination with Microsoft - otherwise the CPU would have been dead in the water because it wouldn't run Windows.

Intel did have IA-64, but I think they felt such power and performance was only for corporate clients and not for the general public (and way too expensive), and it didn't work with the x86. But if it were not for AMD64, intel would still be making 32bit CPUs today (maybe with some 64bit features as a marketing ploy).

But if you have ever worked with large photoshop images, massive Excel spreadsheets and millions of records with SqlServer, you learn to appreciate the capacity of 64bit systems.

Answer 9

Two reasons for 64-bits instead of 32:

1. Double-precision floating point numbers occupy 64 bits (the math is actually performed using 80 bits, but that's another matter). A machine word size of 64 bits allows such values to be moved in a single operation.
2. Block-copy operations are faster the wider the data bus, because you are moving more data at once. This made 16-bit machines superior to 8-bit, and 32-bit machines superior to 16-bit.

At some point in the future, 64-bit machines may give way to 128-bit, but the benefits are not sufficiently compelling yet for general purpose processors, although it can already be seen in special-purpose processors like GPUs.

As for 32 to 64 instead of 48, it's always more convenient (and often more efficient) in a binary-based computer to work in powers of 2. It's not about physical address size, although address size / addressable memory space size is a contributing factor.

Answer 10

It was mainly about marketing. AMD were the first to release a 64bit architecture which allowed them to claim superiority over Intel, while Intel scrambled to release their own, rushed, flawed 64bit chips to market which performed worse than AMDs for a couple of years.

These two time periods - first when AMD could brag about being the most advanced chip when Intel didn't have a 64bit chip on the market, then second when they could brag about being the fastest chip on the market when Intel's first stab at 64bit chips were not very quick - allowed AMD to take a strong lead in sales and performance during 2003 / 2004 when the 64 bit transition happened.

At the time, almost no software made use of the additional power offered by 64bit, and even to this day most applications still run in a 32bit legacy mode "just in case"

Other than supporting much larger memory pools, as you already mention, The chips themselves perform certain internal calculations faster due to the extended address space that 64bit offers, for example you could combine 12 8-bit values in one instruction in a 64bit chip whereas a 32bit chip could only really combine 6. Such performance gains are marginal at best however, and were mainly used for marketing purposes rather than any real-world performance gains.

As for why 64 and not 48, two reasons. One was marketing, 64 is higher than 48, and up to now the "bits" of consumer systems had doubled each time, 8, 16, 32, the next logical number in the sequence was 64. Consumers would (incorrectly) believe that a 64 bit CPU was twice as good as a 32 bit one, prompting them to upgrade more readily than they would when offered a 48 bit CPU. The second reason is more practical, a 64 bit register was twice the size of 32 and therefore in theory it would be easier to port code over to 64 bit than 48.

Arguments about register size aside, it makes logical sense to "go big or go home" when implementing wholesale changes to global computing infrastructure, to avoid having to do such a horrible thing too often. As yet, we haven't needed 128-bit processors, but we probably would be updating from 48-bit to 64-bit about now, so it looks like it was a good call.