What is the word size of a RAM in 32/64 bit machine (processor)
What is the word size of a RAM in 32/64 bit machine (processor) ?
This question is driving me crazy. What is exactly the size of the word that saves the data in the RAM itself in 64bit machines like intel core i5 microprocessors?
Also, does the word size that holds the data changes from 32bit to 64bit?
memory
add a comment |
What is the word size of a RAM in 32/64 bit machine (processor) ?
This question is driving me crazy. What is exactly the size of the word that saves the data in the RAM itself in 64bit machines like intel core i5 microprocessors?
Also, does the word size that holds the data changes from 32bit to 64bit?
memory
add a comment |
What is the word size of a RAM in 32/64 bit machine (processor) ?
This question is driving me crazy. What is exactly the size of the word that saves the data in the RAM itself in 64bit machines like intel core i5 microprocessors?
Also, does the word size that holds the data changes from 32bit to 64bit?
memory
What is the word size of a RAM in 32/64 bit machine (processor) ?
This question is driving me crazy. What is exactly the size of the word that saves the data in the RAM itself in 64bit machines like intel core i5 microprocessors?
Also, does the word size that holds the data changes from 32bit to 64bit?
memory
memory
asked Nov 12 '12 at 11:37
M-T-AM-T-A
12316
12316
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Traditionally, a "word" in computer architectures was generally the smallest addressable unit of memory. And traditionally this has been the same as the machine's general purpose register size.
However, ever since byte addressing became popular, the concept has become diluted. (We can probably credit IBM System/360, and the PDP-11 on the minicomputer side, for this.)
In terms of memory addressing as defined by the CPU architecture - which is to say, how programmers see the machine - the "word" concept does not exist on x86/x64, unless you think of it as synonymous with bytes. Each byte of memory has its own address, and the address of a byte is also the address of any larger region that starts at that byte (extending to higher-numbered addresses). We can of course move one, two, four, or (on x64) eight bytes at a time between register and RAM - or much more, memory-to-memory, with the REP instructions - but the address we assert is still that of a byte. We can do arithmetic on words of all of those sizes. (And others.)
If you think in terms of registers, the "word size" of a machine is normally assumed to be the same as that of its general-purpose registers. This would be 32 bits on x86, 64 bits on x64. On most architectures, the GPR size is the size of the largest integer on which the CPU can perform simple arithmetic with a single instruction.
Now let's introduce more confusion... !
In terms of the platform (motherboard, RAM modules and chips, etc.), on all machines using Intel and AMD "commodity" CPUs and chipsets, RAM is addressed in 64-bit chunks - I suppose you could call them words. You could see this very clearly on earlier processors that had separate pins for address and data: The least-significant address pin is called A3, not A0! Physical address bits A0, A1, and A2 never leave the processor. But programmers never see such addresses.
And finally, there is the concept of a "cache line". A cache line is a physically contiguous chunk of RAM that occupies one entry in the L1/L2/L3 cache. Cache lines in the Intel/AMD world have been 64 bytes wide for some time now. So when you access a memory address that's not currently in your cache the CPU fetches eight of those 8-byte chunks of RAM. To put it another way, the addresses that are stored in the cache omit the low-order six bits. So maybe a word in the cache is really 64 bytes or 512 bits! (But memory access that bypasses the cache can still read or write just 8 bytes at a time; in physical address ranges that are decoded by memory-mapped I/O devices, individual bytes may be addressable; this depends on the bus. And of course we can't do arithmetic on 512-bit integers.)
In Microsoft C-derived programming environments a "word" is 16 bits - it has been so since long before Microsoft, and the name and the definition of the data type has been carried forward to the 32- and 64-bit environments for compatibility. A "double word" (or DWORD or LONG, for "longword", which term was common on the VAX) is 32 bits. 64-bit integers are called "quadwords" in the architecture but usually have more specific names in C, like UINT64 (64-bit integer, unsigned).
So, it depends on where you are in the system and on what you're looking at. We usually don't think about "word size" at all these days, rather "GPR size".
1
"Microsoft C-derived programming environments" got that 16-bit word from Intel official datatype names, so while it's true, it's not exclusive to either Microsoft toolchains, or the C language. And yes, "quadword" is used officially, section 4-1 of Volume 1 of the Intel SDM begins "The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords"
– Ben Voigt
Mar 15 '17 at 19:23
Ah. Thanks! ("quadword" was official at DEC, too, and "longword" or just "long" for 4 bytes)
– Jamie Hanrahan
Mar 15 '17 at 22:10
add a comment |
I'm not familiar with the gory details of how RAM works with Intel CPU's these days given newer stuff like cache coherency and NUMA, but from the RAM's point of view I believe it's still 8-bit bytes, although RAM is now commonly arranged in channels where multiple slots can be accessed at once. So grabbing 4 bytes (assuming 4 slots) at a time is going to take the same amount of time as grabbing 1 byte on such a system. Still, the RAM accepts an address from the memory controller as input and gives it back 8 bits as output AFAIK.
"Word" size can mean different things. I remember first encountering this term studying 68000 assembly language - in the text I was reading, "byte" meant 8 bits and "word" meant 16 bits, and "word-aligned" meant an address falling on a 16-bit boundary. I know the term "word" was in use previously to the introduction of the 68000 (1980?) and may have been synonymous with "byte" in earlier times than that.
The "native" data that the CPU "prefers" to deal with matches the "bitness" of its archtecture and the mode it is running in. A 32-bit CPU (or 64-bit CPU not in "long mode") has 32-bit registers, a bunch of instructions to load values from RAM (4 bytes) into those registers and other stuf. But with Intel, a 32-bit register such as EAX can also be addressed as two registers AH (the upper 16 bits of EAX) and AL (the lower 16 bits) and there are countless MOV instructions that load stuff from RAM into EAX, AH, AL, and from there back to RAM. I'm too lazy to look at the Intel programmer's reference guide right at the moment but I think there's instructions to load single bytes to either the upper or lower 8 bits of AH or AL. (I know MIPS has instructions like that). But I think there's more instructions that work with all 32 bits, and if you want to work with less bits you take a hit in efficiency because you have to move stuf to temporary registers first and such.
So in Intel and most other general purpose CPU's made since the 16-bit era, you are really flexible in how you address memory. Instructions are likely more optimized to work in the "bitness" of the architecture, though.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f504560%2fwhat-is-the-word-size-of-a-ram-in-32-64-bit-machine-processor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Traditionally, a "word" in computer architectures was generally the smallest addressable unit of memory. And traditionally this has been the same as the machine's general purpose register size.
However, ever since byte addressing became popular, the concept has become diluted. (We can probably credit IBM System/360, and the PDP-11 on the minicomputer side, for this.)
In terms of memory addressing as defined by the CPU architecture - which is to say, how programmers see the machine - the "word" concept does not exist on x86/x64, unless you think of it as synonymous with bytes. Each byte of memory has its own address, and the address of a byte is also the address of any larger region that starts at that byte (extending to higher-numbered addresses). We can of course move one, two, four, or (on x64) eight bytes at a time between register and RAM - or much more, memory-to-memory, with the REP instructions - but the address we assert is still that of a byte. We can do arithmetic on words of all of those sizes. (And others.)
If you think in terms of registers, the "word size" of a machine is normally assumed to be the same as that of its general-purpose registers. This would be 32 bits on x86, 64 bits on x64. On most architectures, the GPR size is the size of the largest integer on which the CPU can perform simple arithmetic with a single instruction.
Now let's introduce more confusion... !
In terms of the platform (motherboard, RAM modules and chips, etc.), on all machines using Intel and AMD "commodity" CPUs and chipsets, RAM is addressed in 64-bit chunks - I suppose you could call them words. You could see this very clearly on earlier processors that had separate pins for address and data: The least-significant address pin is called A3, not A0! Physical address bits A0, A1, and A2 never leave the processor. But programmers never see such addresses.
And finally, there is the concept of a "cache line". A cache line is a physically contiguous chunk of RAM that occupies one entry in the L1/L2/L3 cache. Cache lines in the Intel/AMD world have been 64 bytes wide for some time now. So when you access a memory address that's not currently in your cache the CPU fetches eight of those 8-byte chunks of RAM. To put it another way, the addresses that are stored in the cache omit the low-order six bits. So maybe a word in the cache is really 64 bytes or 512 bits! (But memory access that bypasses the cache can still read or write just 8 bytes at a time; in physical address ranges that are decoded by memory-mapped I/O devices, individual bytes may be addressable; this depends on the bus. And of course we can't do arithmetic on 512-bit integers.)
In Microsoft C-derived programming environments a "word" is 16 bits - it has been so since long before Microsoft, and the name and the definition of the data type has been carried forward to the 32- and 64-bit environments for compatibility. A "double word" (or DWORD or LONG, for "longword", which term was common on the VAX) is 32 bits. 64-bit integers are called "quadwords" in the architecture but usually have more specific names in C, like UINT64 (64-bit integer, unsigned).
So, it depends on where you are in the system and on what you're looking at. We usually don't think about "word size" at all these days, rather "GPR size".
1
"Microsoft C-derived programming environments" got that 16-bit word from Intel official datatype names, so while it's true, it's not exclusive to either Microsoft toolchains, or the C language. And yes, "quadword" is used officially, section 4-1 of Volume 1 of the Intel SDM begins "The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords"
– Ben Voigt
Mar 15 '17 at 19:23
Ah. Thanks! ("quadword" was official at DEC, too, and "longword" or just "long" for 4 bytes)
– Jamie Hanrahan
Mar 15 '17 at 22:10
add a comment |
Traditionally, a "word" in computer architectures was generally the smallest addressable unit of memory. And traditionally this has been the same as the machine's general purpose register size.
However, ever since byte addressing became popular, the concept has become diluted. (We can probably credit IBM System/360, and the PDP-11 on the minicomputer side, for this.)
In terms of memory addressing as defined by the CPU architecture - which is to say, how programmers see the machine - the "word" concept does not exist on x86/x64, unless you think of it as synonymous with bytes. Each byte of memory has its own address, and the address of a byte is also the address of any larger region that starts at that byte (extending to higher-numbered addresses). We can of course move one, two, four, or (on x64) eight bytes at a time between register and RAM - or much more, memory-to-memory, with the REP instructions - but the address we assert is still that of a byte. We can do arithmetic on words of all of those sizes. (And others.)
If you think in terms of registers, the "word size" of a machine is normally assumed to be the same as that of its general-purpose registers. This would be 32 bits on x86, 64 bits on x64. On most architectures, the GPR size is the size of the largest integer on which the CPU can perform simple arithmetic with a single instruction.
Now let's introduce more confusion... !
In terms of the platform (motherboard, RAM modules and chips, etc.), on all machines using Intel and AMD "commodity" CPUs and chipsets, RAM is addressed in 64-bit chunks - I suppose you could call them words. You could see this very clearly on earlier processors that had separate pins for address and data: The least-significant address pin is called A3, not A0! Physical address bits A0, A1, and A2 never leave the processor. But programmers never see such addresses.
And finally, there is the concept of a "cache line". A cache line is a physically contiguous chunk of RAM that occupies one entry in the L1/L2/L3 cache. Cache lines in the Intel/AMD world have been 64 bytes wide for some time now. So when you access a memory address that's not currently in your cache the CPU fetches eight of those 8-byte chunks of RAM. To put it another way, the addresses that are stored in the cache omit the low-order six bits. So maybe a word in the cache is really 64 bytes or 512 bits! (But memory access that bypasses the cache can still read or write just 8 bytes at a time; in physical address ranges that are decoded by memory-mapped I/O devices, individual bytes may be addressable; this depends on the bus. And of course we can't do arithmetic on 512-bit integers.)
In Microsoft C-derived programming environments a "word" is 16 bits - it has been so since long before Microsoft, and the name and the definition of the data type has been carried forward to the 32- and 64-bit environments for compatibility. A "double word" (or DWORD or LONG, for "longword", which term was common on the VAX) is 32 bits. 64-bit integers are called "quadwords" in the architecture but usually have more specific names in C, like UINT64 (64-bit integer, unsigned).
So, it depends on where you are in the system and on what you're looking at. We usually don't think about "word size" at all these days, rather "GPR size".
1
"Microsoft C-derived programming environments" got that 16-bit word from Intel official datatype names, so while it's true, it's not exclusive to either Microsoft toolchains, or the C language. And yes, "quadword" is used officially, section 4-1 of Volume 1 of the Intel SDM begins "The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords"
– Ben Voigt
Mar 15 '17 at 19:23
Ah. Thanks! ("quadword" was official at DEC, too, and "longword" or just "long" for 4 bytes)
– Jamie Hanrahan
Mar 15 '17 at 22:10
add a comment |
Traditionally, a "word" in computer architectures was generally the smallest addressable unit of memory. And traditionally this has been the same as the machine's general purpose register size.
However, ever since byte addressing became popular, the concept has become diluted. (We can probably credit IBM System/360, and the PDP-11 on the minicomputer side, for this.)
In terms of memory addressing as defined by the CPU architecture - which is to say, how programmers see the machine - the "word" concept does not exist on x86/x64, unless you think of it as synonymous with bytes. Each byte of memory has its own address, and the address of a byte is also the address of any larger region that starts at that byte (extending to higher-numbered addresses). We can of course move one, two, four, or (on x64) eight bytes at a time between register and RAM - or much more, memory-to-memory, with the REP instructions - but the address we assert is still that of a byte. We can do arithmetic on words of all of those sizes. (And others.)
If you think in terms of registers, the "word size" of a machine is normally assumed to be the same as that of its general-purpose registers. This would be 32 bits on x86, 64 bits on x64. On most architectures, the GPR size is the size of the largest integer on which the CPU can perform simple arithmetic with a single instruction.
Now let's introduce more confusion... !
In terms of the platform (motherboard, RAM modules and chips, etc.), on all machines using Intel and AMD "commodity" CPUs and chipsets, RAM is addressed in 64-bit chunks - I suppose you could call them words. You could see this very clearly on earlier processors that had separate pins for address and data: The least-significant address pin is called A3, not A0! Physical address bits A0, A1, and A2 never leave the processor. But programmers never see such addresses.
And finally, there is the concept of a "cache line". A cache line is a physically contiguous chunk of RAM that occupies one entry in the L1/L2/L3 cache. Cache lines in the Intel/AMD world have been 64 bytes wide for some time now. So when you access a memory address that's not currently in your cache the CPU fetches eight of those 8-byte chunks of RAM. To put it another way, the addresses that are stored in the cache omit the low-order six bits. So maybe a word in the cache is really 64 bytes or 512 bits! (But memory access that bypasses the cache can still read or write just 8 bytes at a time; in physical address ranges that are decoded by memory-mapped I/O devices, individual bytes may be addressable; this depends on the bus. And of course we can't do arithmetic on 512-bit integers.)
In Microsoft C-derived programming environments a "word" is 16 bits - it has been so since long before Microsoft, and the name and the definition of the data type has been carried forward to the 32- and 64-bit environments for compatibility. A "double word" (or DWORD or LONG, for "longword", which term was common on the VAX) is 32 bits. 64-bit integers are called "quadwords" in the architecture but usually have more specific names in C, like UINT64 (64-bit integer, unsigned).
So, it depends on where you are in the system and on what you're looking at. We usually don't think about "word size" at all these days, rather "GPR size".
Traditionally, a "word" in computer architectures was generally the smallest addressable unit of memory. And traditionally this has been the same as the machine's general purpose register size.
However, ever since byte addressing became popular, the concept has become diluted. (We can probably credit IBM System/360, and the PDP-11 on the minicomputer side, for this.)
In terms of memory addressing as defined by the CPU architecture - which is to say, how programmers see the machine - the "word" concept does not exist on x86/x64, unless you think of it as synonymous with bytes. Each byte of memory has its own address, and the address of a byte is also the address of any larger region that starts at that byte (extending to higher-numbered addresses). We can of course move one, two, four, or (on x64) eight bytes at a time between register and RAM - or much more, memory-to-memory, with the REP instructions - but the address we assert is still that of a byte. We can do arithmetic on words of all of those sizes. (And others.)
If you think in terms of registers, the "word size" of a machine is normally assumed to be the same as that of its general-purpose registers. This would be 32 bits on x86, 64 bits on x64. On most architectures, the GPR size is the size of the largest integer on which the CPU can perform simple arithmetic with a single instruction.
Now let's introduce more confusion... !
In terms of the platform (motherboard, RAM modules and chips, etc.), on all machines using Intel and AMD "commodity" CPUs and chipsets, RAM is addressed in 64-bit chunks - I suppose you could call them words. You could see this very clearly on earlier processors that had separate pins for address and data: The least-significant address pin is called A3, not A0! Physical address bits A0, A1, and A2 never leave the processor. But programmers never see such addresses.
And finally, there is the concept of a "cache line". A cache line is a physically contiguous chunk of RAM that occupies one entry in the L1/L2/L3 cache. Cache lines in the Intel/AMD world have been 64 bytes wide for some time now. So when you access a memory address that's not currently in your cache the CPU fetches eight of those 8-byte chunks of RAM. To put it another way, the addresses that are stored in the cache omit the low-order six bits. So maybe a word in the cache is really 64 bytes or 512 bits! (But memory access that bypasses the cache can still read or write just 8 bytes at a time; in physical address ranges that are decoded by memory-mapped I/O devices, individual bytes may be addressable; this depends on the bus. And of course we can't do arithmetic on 512-bit integers.)
In Microsoft C-derived programming environments a "word" is 16 bits - it has been so since long before Microsoft, and the name and the definition of the data type has been carried forward to the 32- and 64-bit environments for compatibility. A "double word" (or DWORD or LONG, for "longword", which term was common on the VAX) is 32 bits. 64-bit integers are called "quadwords" in the architecture but usually have more specific names in C, like UINT64 (64-bit integer, unsigned).
So, it depends on where you are in the system and on what you're looking at. We usually don't think about "word size" at all these days, rather "GPR size".
edited Feb 16 at 3:52
answered Mar 13 '17 at 22:31
Jamie HanrahanJamie Hanrahan
18.9k34280
18.9k34280
1
"Microsoft C-derived programming environments" got that 16-bit word from Intel official datatype names, so while it's true, it's not exclusive to either Microsoft toolchains, or the C language. And yes, "quadword" is used officially, section 4-1 of Volume 1 of the Intel SDM begins "The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords"
– Ben Voigt
Mar 15 '17 at 19:23
Ah. Thanks! ("quadword" was official at DEC, too, and "longword" or just "long" for 4 bytes)
– Jamie Hanrahan
Mar 15 '17 at 22:10
add a comment |
1
"Microsoft C-derived programming environments" got that 16-bit word from Intel official datatype names, so while it's true, it's not exclusive to either Microsoft toolchains, or the C language. And yes, "quadword" is used officially, section 4-1 of Volume 1 of the Intel SDM begins "The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords"
– Ben Voigt
Mar 15 '17 at 19:23
Ah. Thanks! ("quadword" was official at DEC, too, and "longword" or just "long" for 4 bytes)
– Jamie Hanrahan
Mar 15 '17 at 22:10
1
1
"Microsoft C-derived programming environments" got that 16-bit word from Intel official datatype names, so while it's true, it's not exclusive to either Microsoft toolchains, or the C language. And yes, "quadword" is used officially, section 4-1 of Volume 1 of the Intel SDM begins "The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords"
– Ben Voigt
Mar 15 '17 at 19:23
"Microsoft C-derived programming environments" got that 16-bit word from Intel official datatype names, so while it's true, it's not exclusive to either Microsoft toolchains, or the C language. And yes, "quadword" is used officially, section 4-1 of Volume 1 of the Intel SDM begins "The fundamental data types are bytes, words, doublewords, quadwords, and double quadwords"
– Ben Voigt
Mar 15 '17 at 19:23
Ah. Thanks! ("quadword" was official at DEC, too, and "longword" or just "long" for 4 bytes)
– Jamie Hanrahan
Mar 15 '17 at 22:10
Ah. Thanks! ("quadword" was official at DEC, too, and "longword" or just "long" for 4 bytes)
– Jamie Hanrahan
Mar 15 '17 at 22:10
add a comment |
I'm not familiar with the gory details of how RAM works with Intel CPU's these days given newer stuff like cache coherency and NUMA, but from the RAM's point of view I believe it's still 8-bit bytes, although RAM is now commonly arranged in channels where multiple slots can be accessed at once. So grabbing 4 bytes (assuming 4 slots) at a time is going to take the same amount of time as grabbing 1 byte on such a system. Still, the RAM accepts an address from the memory controller as input and gives it back 8 bits as output AFAIK.
"Word" size can mean different things. I remember first encountering this term studying 68000 assembly language - in the text I was reading, "byte" meant 8 bits and "word" meant 16 bits, and "word-aligned" meant an address falling on a 16-bit boundary. I know the term "word" was in use previously to the introduction of the 68000 (1980?) and may have been synonymous with "byte" in earlier times than that.
The "native" data that the CPU "prefers" to deal with matches the "bitness" of its archtecture and the mode it is running in. A 32-bit CPU (or 64-bit CPU not in "long mode") has 32-bit registers, a bunch of instructions to load values from RAM (4 bytes) into those registers and other stuf. But with Intel, a 32-bit register such as EAX can also be addressed as two registers AH (the upper 16 bits of EAX) and AL (the lower 16 bits) and there are countless MOV instructions that load stuff from RAM into EAX, AH, AL, and from there back to RAM. I'm too lazy to look at the Intel programmer's reference guide right at the moment but I think there's instructions to load single bytes to either the upper or lower 8 bits of AH or AL. (I know MIPS has instructions like that). But I think there's more instructions that work with all 32 bits, and if you want to work with less bits you take a hit in efficiency because you have to move stuf to temporary registers first and such.
So in Intel and most other general purpose CPU's made since the 16-bit era, you are really flexible in how you address memory. Instructions are likely more optimized to work in the "bitness" of the architecture, though.
add a comment |
I'm not familiar with the gory details of how RAM works with Intel CPU's these days given newer stuff like cache coherency and NUMA, but from the RAM's point of view I believe it's still 8-bit bytes, although RAM is now commonly arranged in channels where multiple slots can be accessed at once. So grabbing 4 bytes (assuming 4 slots) at a time is going to take the same amount of time as grabbing 1 byte on such a system. Still, the RAM accepts an address from the memory controller as input and gives it back 8 bits as output AFAIK.
"Word" size can mean different things. I remember first encountering this term studying 68000 assembly language - in the text I was reading, "byte" meant 8 bits and "word" meant 16 bits, and "word-aligned" meant an address falling on a 16-bit boundary. I know the term "word" was in use previously to the introduction of the 68000 (1980?) and may have been synonymous with "byte" in earlier times than that.
The "native" data that the CPU "prefers" to deal with matches the "bitness" of its archtecture and the mode it is running in. A 32-bit CPU (or 64-bit CPU not in "long mode") has 32-bit registers, a bunch of instructions to load values from RAM (4 bytes) into those registers and other stuf. But with Intel, a 32-bit register such as EAX can also be addressed as two registers AH (the upper 16 bits of EAX) and AL (the lower 16 bits) and there are countless MOV instructions that load stuff from RAM into EAX, AH, AL, and from there back to RAM. I'm too lazy to look at the Intel programmer's reference guide right at the moment but I think there's instructions to load single bytes to either the upper or lower 8 bits of AH or AL. (I know MIPS has instructions like that). But I think there's more instructions that work with all 32 bits, and if you want to work with less bits you take a hit in efficiency because you have to move stuf to temporary registers first and such.
So in Intel and most other general purpose CPU's made since the 16-bit era, you are really flexible in how you address memory. Instructions are likely more optimized to work in the "bitness" of the architecture, though.
add a comment |
I'm not familiar with the gory details of how RAM works with Intel CPU's these days given newer stuff like cache coherency and NUMA, but from the RAM's point of view I believe it's still 8-bit bytes, although RAM is now commonly arranged in channels where multiple slots can be accessed at once. So grabbing 4 bytes (assuming 4 slots) at a time is going to take the same amount of time as grabbing 1 byte on such a system. Still, the RAM accepts an address from the memory controller as input and gives it back 8 bits as output AFAIK.
"Word" size can mean different things. I remember first encountering this term studying 68000 assembly language - in the text I was reading, "byte" meant 8 bits and "word" meant 16 bits, and "word-aligned" meant an address falling on a 16-bit boundary. I know the term "word" was in use previously to the introduction of the 68000 (1980?) and may have been synonymous with "byte" in earlier times than that.
The "native" data that the CPU "prefers" to deal with matches the "bitness" of its archtecture and the mode it is running in. A 32-bit CPU (or 64-bit CPU not in "long mode") has 32-bit registers, a bunch of instructions to load values from RAM (4 bytes) into those registers and other stuf. But with Intel, a 32-bit register such as EAX can also be addressed as two registers AH (the upper 16 bits of EAX) and AL (the lower 16 bits) and there are countless MOV instructions that load stuff from RAM into EAX, AH, AL, and from there back to RAM. I'm too lazy to look at the Intel programmer's reference guide right at the moment but I think there's instructions to load single bytes to either the upper or lower 8 bits of AH or AL. (I know MIPS has instructions like that). But I think there's more instructions that work with all 32 bits, and if you want to work with less bits you take a hit in efficiency because you have to move stuf to temporary registers first and such.
So in Intel and most other general purpose CPU's made since the 16-bit era, you are really flexible in how you address memory. Instructions are likely more optimized to work in the "bitness" of the architecture, though.
I'm not familiar with the gory details of how RAM works with Intel CPU's these days given newer stuff like cache coherency and NUMA, but from the RAM's point of view I believe it's still 8-bit bytes, although RAM is now commonly arranged in channels where multiple slots can be accessed at once. So grabbing 4 bytes (assuming 4 slots) at a time is going to take the same amount of time as grabbing 1 byte on such a system. Still, the RAM accepts an address from the memory controller as input and gives it back 8 bits as output AFAIK.
"Word" size can mean different things. I remember first encountering this term studying 68000 assembly language - in the text I was reading, "byte" meant 8 bits and "word" meant 16 bits, and "word-aligned" meant an address falling on a 16-bit boundary. I know the term "word" was in use previously to the introduction of the 68000 (1980?) and may have been synonymous with "byte" in earlier times than that.
The "native" data that the CPU "prefers" to deal with matches the "bitness" of its archtecture and the mode it is running in. A 32-bit CPU (or 64-bit CPU not in "long mode") has 32-bit registers, a bunch of instructions to load values from RAM (4 bytes) into those registers and other stuf. But with Intel, a 32-bit register such as EAX can also be addressed as two registers AH (the upper 16 bits of EAX) and AL (the lower 16 bits) and there are countless MOV instructions that load stuff from RAM into EAX, AH, AL, and from there back to RAM. I'm too lazy to look at the Intel programmer's reference guide right at the moment but I think there's instructions to load single bytes to either the upper or lower 8 bits of AH or AL. (I know MIPS has instructions like that). But I think there's more instructions that work with all 32 bits, and if you want to work with less bits you take a hit in efficiency because you have to move stuf to temporary registers first and such.
So in Intel and most other general purpose CPU's made since the 16-bit era, you are really flexible in how you address memory. Instructions are likely more optimized to work in the "bitness" of the architecture, though.
answered Nov 12 '12 at 12:06
LawrenceCLawrenceC
59.5k11103181
59.5k11103181
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f504560%2fwhat-is-the-word-size-of-a-ram-in-32-64-bit-machine-processor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown