Even the newest “64-bit” cpus are really just 48-bit (or 36-bit on low end) or if bleeding edge 56-bit physical adressing processors. This is the maximum amount of virtual memory a process can have access to. You could memory map all your hard disks an still have room to map more physical memory to VMA.
We do, depending on how you count it.
There’s two major widths in a processor. The data register width and the address bus width, but even that is not the whole story. If you go back to a processor like the 68000, the classic 16-bit processor, it has:
- 32-bit data registers
- 16- bit ALU
- 16-bit data bus
- 32-bit address registers
- 24-bit address bus
Some people called it a 16/32 bit processor, but really it was the 16-bit ALU that classified it as 16-bits.
If you look at a Zen 4 core it has:
- 64-bit data registers
- 512-bit AVX data registers
- 6 x 64-bit integer ALUs
- 4 x 256-bit AVX ALUs
- 2 x 128-bit data bus to DDR5 (dual edge 64-bit)
- ~40-bits of addressable physical RAM
So, what do you want to call this processor?
64-bit (integer width), 128-bit (physical data bus width), 256-bit (widest ALU) or 512-bit (widest register width)? Do you want to multiply those numbers up by the number of ALUs in a core? …by the number of cores on a piece of silicon?
Me, I’d say Zen4 was a 256-bit core, but you could argue any of the above numbers.
Basically, it’s a measurement that lost all meaning so people stopped using it.
I see it as the number of possible instructions.
As in, 8 bit 8085 had 28 possible instructions, 32 bit ones had 232 and already had enough possible combinations that we couldn’t come up with enough functions to fill the provided space.
So “instruction encoding length”.
I don’t think that works though. For something like RISC-V, RV64 has a maximum 32-bit instruction encoding. For x86-64 those original 8-bit intructions still exist, and take up a huge part of the encoding space, cutting the number of n-bit instructions to more like 2^(n-7)
RV64 has a maximum 32-bit instruction encoding
I kinda expected that to happen, since there’s already enough to fit all required functions. So yeah, even this is not a good enough criteria for bit rating.
those original 8-bit intructions still exist, and take up a huge part of the encoding space, cutting the number of n-bit instructions to more like 2^(n-7)
err… they are still instructions, right? And they are implemented. I don’t see why you would negate that from the number of instructions.
I gave up trying to figure out what the “bitness” of CPUs were around the time the Atari Jaguar came out and people described it as 64 bit because it had 32 bit graphics chip plus a 32 bit sound chip.
It’s been mostly marketing bollocks since forever.
I would say that you make a decent argument that the ALU has the strongest claim to the “bitness” of a CPU. In that way, we are already beyond 64 bit.
For me though, what really defines a CPU is the software that runs natively. The Zen4 runs software written for the AMD64 family of processors. That is, it runs 64 bit software. This software will not run on the “32 bit” x86 processors that came before it ( like the K5, K6, and original Athlon ). If AMD released the AMD128 instruction set, it would not run on the Zen4 even though it may technically be enough hardware to do so.
The Motorola 68000 only had a 16 but ALU but was able to run the same 32 bit software that ran in later Motorola processors that were truly 32 bit. Software written for the 68000 was essentially still native on processors sold as late as 2014 ( 35 years after the 68000 was released ). This was not some kid of compatibility mode, these processors were still using the same 32 bit ISA.
The Linux kernel that runs on the Zen4 will also run on 64 bit machines made 20 years ago as they also support the amd64 / x86-64 ISA.
Where the article is correct is that there does not seem to be much push to move on from 64 bit software. The Zen4 supports instructions to perform higher-bit operations but they are optional. Most applications do not rely on them, including the operating system. For the most part, the Zen4 runs the same software as the Opteron ( released in 2003 ). The same pre-compiled Linux distro will run on both.
I’m surprised some marketing genius at the intel/amd hasnt started using the bigger numbers
I expect the engineers are telling the marketing people “No! You can’t do that. You’ll scare everyone that it’s incompatible.”
At less than a tenth the size, this is actually a better explanation than the article. Already correcting the fact that we do at the very beginning.
If you absolutely had to put a bit width on the Zen 4, the 2x128 bit data bus is probably the best single measure totaling 256 bit IMO.
Even then, at what point do you measure it? DDR interface is likely very much narrower than the interfaces between cache levels. Where does the core end and the memory begin?
Yes you are 100% right, and I did consider level 3 cache as a better measure, because that allows communication between cores without the need to go through RAM, and cache generally has a high hit rate. But this number was surprisingly difficult to find, so I settled on the data bus.
Anyways it would be absolutely fair to call it 256bit by more than one measure. But for sure it isn’t just 64 bit, because it has 512 bit instructions, so the instruction set isn’t limited to 64 bit. Even if someone was stubborn enough to claim the general instruction set is 64 bit, it has the ability to decode and execute 2 simultaneous 64 bit instructions per core, making at least 128 bit by any measure.
tell that to playstation2 owners
Okay, so why can’t we just not use exponentially growing values? Like 96 bit (64 + 36). I’d the something intrinsic about the size increases that they HAVE to be exponential? Why not linear scaling? 8, 16, 24, 32, 40, 48, 56, 64, 72, 80, etc.
We can, but it’s awkward to do so. By having everything work with powers of 2 you don’t need to have everything the same size, but can still pack things in memory efficiently.
If your registers were 48bits long, you can use it to store 6 bytes, or 3 short ints, but only one int with 16-bits going unused. If they are powers of two in size, you can always fit smaller things in them with no wasted space.
