Athlon64
- Thread starter sonofangron
- Start date
64 Bit refers to the size of the registers located on the processor. To put it simple, say we want to add to numbers together like 2 + 4, each value is stored in tiny memory area's closer to the die then even the L1 cache. Both value's have to be stored in seperate registers untill the operation can be performed, the final value of 5 is stored in a 3rd register for transfer out, anything bit of data processed at one point will end up in a register and like most things in the desktop (THE MORE THE BETTER)
The only downside is that data stored in the registers must be larger then 32 Bit in order for their to be performance gain, not likely with current software. Say for instants you add a number such as 2,000,000 with 4,000,000, you are still going to need a register for each value and one for the answer and your PC does not care how large the registers are cause you can only store one value in them at a given time.
To access RAM in a PC, the processor needs the address of that location which is a number representing 1 byte of storage, 32 Bit can address 4.3 Billion memory address's for up to 4 GB of RAM while 64 Bit can access up to 18 petabytes.
The only downside is that data stored in the registers must be larger then 32 Bit in order for their to be performance gain, not likely with current software. Say for instants you add a number such as 2,000,000 with 4,000,000, you are still going to need a register for each value and one for the answer and your PC does not care how large the registers are cause you can only store one value in them at a given time.
To access RAM in a PC, the processor needs the address of that location which is a number representing 1 byte of storage, 32 Bit can address 4.3 Billion memory address's for up to 4 GB of RAM while 64 Bit can access up to 18 petabytes.
Mik3y's short answer is the most accurate. In fact it is entirely accurate.
The A64 is a 64-bit CPU. An explanation of what that means, involves understanding software and even machine code to some degree.
Traditionally, (pre 80'ies) the 'bitness' of a cpu, has often concerned the length of some registers. While the length of GPR still holds in this regard, that explanation is inadequate since it doesn't really tell the real significance. Contrary, it's actually misleading, since it hints that the issue is some width of processing. The GPRs and paths inside the A64 are indeed generalized to 64 bits, but that's not the main issue. (And total width of processing in an A64 can actually be as much as 384 bits, so never mind that width paradigm. It belongs to game consoles, not modern CPUs.)
Further, our 32-bit cpus have had 64-bit and even 128-bit long registers for some time now, so explaining 64-bitness in terms of register width, may be confusing and is not an expedient task. At least not if you want someone to actually understand what 64-bitness means.
Accessing ram doesn't have terribly much directly with 64-bitness to do either. True, it is involved, but it's more subtle than that. And again, a too simple explanation may mislead to wrong conclusions.
Machine code instructions do very simple things. They manipulate bit fields. The bitfield length can be anything from 8, 16, 32, 64, 128 ([8,8,8,8,8,8,8,8] to [64,64]). A single bit field can be inverted, rotated, shifted or set to some explicit value. Two bit fields can be AND-ed, OR-ed, ADD-ed, IMUL-ed, compared etc...
For all this to work, the processor must be able to know WHAT instruction to execute next. It must be able to refer to the instruction. Each instruction must also be able to refer to the bit fields it is going to manipulate. All this, from the software's point of view, is done by something called virtual address. This is simply a number, explicitly stated or derived in some fashion.
The functional model for this, is that all program instructions and all data exist in a numbered space. This is the virtual space. For each 8 bits of digital data, each byte in the space, there is a number. Instructions that want to refer to some data in this space, do so by the number corresponding to the "location" of the first byte of the involved data.
"16-bit" software is made up out of machine code instructions that use 16 bits long numbers to refer to "location" of instructions and data.
"32-bit" software is made up out of machine code instructions that use 32 bits long numbers to refer to "location" of instructions and data.
"64-bit" software is made up out of machine code instructions that use 64 bits long numbers to refer to "location" of instructions and data.
A 16-bit cpu is a cpu that can only run 16-bit software.
A 32-bit cpu is a cpu that can run 32-bit software.
A 64-bit cpu is a cpu that can run 64-bit software.
For the sake of software simplicity, efficiency and reliability, it's extremely beneficial to have a very large flat virtual space. The flat space in a 16-bit software model is only 64KB. The flat space for 32-bit software is 4GB, and finally the flat space for 64-bit software is 16EB (1 ExoByte = 1024 PetaByte, 1PB = 1024TB, 1TB = 1024GB).
There are two reasons for this. First of all, if the program and its data (and it's API calls) cannot be held within a single flat addressing space, the software must have several flat spaces, and itself must explicitely know and keep track of which address space, or segment, contains every single piece of data involved. The software then has a segmented virtual space. This is very very bad. The software application must then also make sure that the correct segment is always set in the CPU's segment register. This is contorted and inefficient, to say the very least.
But that was how 16-bit software worked. Remember Windows3.11? The big revolution of 32-bit software and Win95/NT was that the segmented software model was dispensed with. Our current 32-bit software is in fact based on the concept of a separate single flat virtual space, for each and every process running under the OS.
But 32-bit software only goes so far. The virtual space becomes fragmented! This is very important to remember. We cannot use it all. Ideally, we should have a much, much larger flat virtual space than we can ever use. Whenever the software figures to set up another large block of data, there should be no problem of finding free "numbers" for referring to that data. It's also important to remember that the OS' services and resources also must be mapped in, as well as any "shared" resources.
Today, the limit where a 32-bit application risks stop working, is somewhere around 1½ GB, used for code and data.
There are only two solutions to this. Either we go back to a segmented software model, with all it's problems and limitations, or we go to a 64-bit software model. The choice is extremely clear. And actually already made for us by both MS, Windows64, and Linux. Noone intends to go 32-bit segmented. Oracle did, for lack of better options, but that's not the future.
Accessing ram:
Physical RAM then works this way: Every "number", ie virtual address that is in actual use by the software, (or any software currently running) is associated with an unique current location in either physical ram or in swap area. This work is handled by the CPU's memory manager and the OS. This physical memory doesn't become fragmented, thanks to a paging mechanism.
This paging mechanism can handle more than 4GB physical ram, even for 32-bit software (segmented), like 36-bit physical address (64GB), for instance. So this often stated 4GB limitation of 32-bit CPUs is simply not true!
What is true, however, is that our current 32-bit software format, is much more limited than that. Large software tools run aground somewhere after ~1½Gb, like maybe 1.7GB. So the often also stated assumption that we're fine on 32-bit CPUs, as long as we don't need 4GB, is likewise also unfortunately a lie.
The A64 is a 64-bit CPU. An explanation of what that means, involves understanding software and even machine code to some degree.
Traditionally, (pre 80'ies) the 'bitness' of a cpu, has often concerned the length of some registers. While the length of GPR still holds in this regard, that explanation is inadequate since it doesn't really tell the real significance. Contrary, it's actually misleading, since it hints that the issue is some width of processing. The GPRs and paths inside the A64 are indeed generalized to 64 bits, but that's not the main issue. (And total width of processing in an A64 can actually be as much as 384 bits, so never mind that width paradigm. It belongs to game consoles, not modern CPUs.)
Further, our 32-bit cpus have had 64-bit and even 128-bit long registers for some time now, so explaining 64-bitness in terms of register width, may be confusing and is not an expedient task. At least not if you want someone to actually understand what 64-bitness means.
Accessing ram doesn't have terribly much directly with 64-bitness to do either. True, it is involved, but it's more subtle than that. And again, a too simple explanation may mislead to wrong conclusions.
Machine code instructions do very simple things. They manipulate bit fields. The bitfield length can be anything from 8, 16, 32, 64, 128 ([8,8,8,8,8,8,8,8] to [64,64]). A single bit field can be inverted, rotated, shifted or set to some explicit value. Two bit fields can be AND-ed, OR-ed, ADD-ed, IMUL-ed, compared etc...
For all this to work, the processor must be able to know WHAT instruction to execute next. It must be able to refer to the instruction. Each instruction must also be able to refer to the bit fields it is going to manipulate. All this, from the software's point of view, is done by something called virtual address. This is simply a number, explicitly stated or derived in some fashion.
The functional model for this, is that all program instructions and all data exist in a numbered space. This is the virtual space. For each 8 bits of digital data, each byte in the space, there is a number. Instructions that want to refer to some data in this space, do so by the number corresponding to the "location" of the first byte of the involved data.
"16-bit" software is made up out of machine code instructions that use 16 bits long numbers to refer to "location" of instructions and data.
"32-bit" software is made up out of machine code instructions that use 32 bits long numbers to refer to "location" of instructions and data.
"64-bit" software is made up out of machine code instructions that use 64 bits long numbers to refer to "location" of instructions and data.
A 16-bit cpu is a cpu that can only run 16-bit software.
A 32-bit cpu is a cpu that can run 32-bit software.
A 64-bit cpu is a cpu that can run 64-bit software.
For the sake of software simplicity, efficiency and reliability, it's extremely beneficial to have a very large flat virtual space. The flat space in a 16-bit software model is only 64KB. The flat space for 32-bit software is 4GB, and finally the flat space for 64-bit software is 16EB (1 ExoByte = 1024 PetaByte, 1PB = 1024TB, 1TB = 1024GB).
There are two reasons for this. First of all, if the program and its data (and it's API calls) cannot be held within a single flat addressing space, the software must have several flat spaces, and itself must explicitely know and keep track of which address space, or segment, contains every single piece of data involved. The software then has a segmented virtual space. This is very very bad. The software application must then also make sure that the correct segment is always set in the CPU's segment register. This is contorted and inefficient, to say the very least.
But that was how 16-bit software worked. Remember Windows3.11? The big revolution of 32-bit software and Win95/NT was that the segmented software model was dispensed with. Our current 32-bit software is in fact based on the concept of a separate single flat virtual space, for each and every process running under the OS.
But 32-bit software only goes so far. The virtual space becomes fragmented! This is very important to remember. We cannot use it all. Ideally, we should have a much, much larger flat virtual space than we can ever use. Whenever the software figures to set up another large block of data, there should be no problem of finding free "numbers" for referring to that data. It's also important to remember that the OS' services and resources also must be mapped in, as well as any "shared" resources.
Today, the limit where a 32-bit application risks stop working, is somewhere around 1½ GB, used for code and data.
There are only two solutions to this. Either we go back to a segmented software model, with all it's problems and limitations, or we go to a 64-bit software model. The choice is extremely clear. And actually already made for us by both MS, Windows64, and Linux. Noone intends to go 32-bit segmented. Oracle did, for lack of better options, but that's not the future.
Accessing ram:
Physical RAM then works this way: Every "number", ie virtual address that is in actual use by the software, (or any software currently running) is associated with an unique current location in either physical ram or in swap area. This work is handled by the CPU's memory manager and the OS. This physical memory doesn't become fragmented, thanks to a paging mechanism.
This paging mechanism can handle more than 4GB physical ram, even for 32-bit software (segmented), like 36-bit physical address (64GB), for instance. So this often stated 4GB limitation of 32-bit CPUs is simply not true!
What is true, however, is that our current 32-bit software format, is much more limited than that. Large software tools run aground somewhere after ~1½Gb, like maybe 1.7GB. So the often also stated assumption that we're fine on 32-bit CPUs, as long as we don't need 4GB, is likewise also unfortunately a lie.
Spikesoldier
Diamond Member
- Oct 15, 2001
- 6,766
- 0
- 0
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 20K
-
-
-
Facebook
Twitter