X86-64 question
Hi guys,
So as I understand computer memory is generally byte addressable, but I have read that the data lines on x86-64 processors are 64 bits wide, when the processor receives data from memory does it do so 64 bits at a time or 8 bits? and if 64 bits, why do we call memory byte addressable?
Also let's say I want to read a byte from memory to store in a char(1 byte), does the CPU still fetch 64 bits of data from memory?
So as I understand computer memory is generally byte addressable, but I have read that the data lines on x86-64 processors are 64 bits wide, when the processor receives data from memory does it do so 64 bits at a time or 8 bits? and if 64 bits, why do we call memory byte addressable?
Also let's say I want to read a byte from memory to store in a char(1 byte), does the CPU still fetch 64 bits of data from memory?
as far as I know, but I have not worked with it much, 64 bit still has all the old stuff.
the register rax is 64 bits.
you can access eax, though, which is 32 bits.
or you can access ax, which is 16 bits.
or you can access al and ah (low and high) which are 1 byte each.
all those are subsets of the RAX register/circuit.
so as far as I know it is still legal in 64 bit assembly to read one byte from memory into al ... unless I missed a memo on that?
now, the hardware may read 64 bits and throw away most of it for you. I do not know about this.
the register rax is 64 bits.
you can access eax, though, which is 32 bits.
or you can access ax, which is 16 bits.
or you can access al and ah (low and high) which are 1 byte each.
all those are subsets of the RAX register/circuit.
so as far as I know it is still legal in 64 bit assembly to read one byte from memory into al ... unless I missed a memo on that?
now, the hardware may read 64 bits and throw away most of it for you. I do not know about this.
Last edited on
On x86-64*, yes, the smallest read is 64 bits wide, since reading less than that doesn't make anything faster. I'm not sure about writes, though. It's possible that writing fewer bits at a time is allowable.
From a programming standpoint, the particular interface between the memory controller and RAM is irrelevant. You get specific performance and behavior guarantees from the hardware and that's all you need to know. Designing the hardware to meet those guarantees is a problem for the computer engineers at Intel and AMD to solve.
*Note that I'm referring to the hardware architecture, not the ISA. I.e. The microarchitecture. The number of copper traces on the data bus doesn't change when you switch the CPU mode. In other words, an x86-64-capable CPU operating in 32-bit mode will still fetch 64 bits at a time.
From a programming standpoint, the particular interface between the memory controller and RAM is irrelevant. You get specific performance and behavior guarantees from the hardware and that's all you need to know. Designing the hardware to meet those guarantees is a problem for the computer engineers at Intel and AMD to solve.
*Note that I'm referring to the hardware architecture, not the ISA. I.e. The microarchitecture. The number of copper traces on the data bus doesn't change when you switch the CPU mode. In other words, an x86-64-capable CPU operating in 32-bit mode will still fetch 64 bits at a time.
Last edited on
There's also something somewhere about boundary alignment. Every data type should be aligned by its own size - or something like this.
https://memoryexceeded.com/index.php/7728/memory-alignment-on-a-32-bit-intel-processor
https://memoryexceeded.com/index.php/7728/memory-alignment-on-a-32-bit-intel-processor
What is typically meant by byte addressable is that you can call pop on an 8 bit sized value, and it should not overwrite anything other than the 8 bits that are being read into. Each byte can be treated as a separate variable both in RAM and in your CPU register. (Things get more complicated when you want to access all 8 bytes of a register as separate values, but the point is that it can be done.)
What's important to know is that a push or pop from ram takes the same amount of time whether it's an 8 bit, 16 bit, 32 bit, or 64 bit value. Reading from RAM is a lot slower than working on info that is already in the CPU, so whenever you can you are better off calling a 64 bit pop, then work the bytes out into separate registers from there by using the smaller operations.
To the computer, it's all just 1's and 0's, it's up to you to decide how they are put together. It might be easiest to think of your stack in RAM as an array of chars. C++ has implemented the idea of type-safety, where an int is 32 bits, long long is 64 bits, and you get a warning if you try to cram an int into a char. Assembly does not have type-safety. An array of 64 chars might as well be an array of 8 long longs while they rest in RAM, the CPU awaits your instructions on how to deal with that data.
What's important to know is that a push or pop from ram takes the same amount of time whether it's an 8 bit, 16 bit, 32 bit, or 64 bit value. Reading from RAM is a lot slower than working on info that is already in the CPU, so whenever you can you are better off calling a 64 bit pop, then work the bytes out into separate registers from there by using the smaller operations.
To the computer, it's all just 1's and 0's, it's up to you to decide how they are put together. It might be easiest to think of your stack in RAM as an array of chars. C++ has implemented the idea of type-safety, where an int is 32 bits, long long is 64 bits, and you get a warning if you try to cram an int into a char. Assembly does not have type-safety. An array of 64 chars might as well be an array of 8 long longs while they rest in RAM, the CPU awaits your instructions on how to deal with that data.
Last edited on
Topic archived. No new replies allowed.