No, I am saying 4 (bytes/word)*2^32 words, which is 2^34 bytes.
That's wrong. 8bit (1 byte) give you 2^8=256 "cells" of memory; 16 (2 bytes) 2^16 = 64K; 32 bits (4 bytes) is 4,294,967,296 (4Gb). It has nothing to do with number of bytes in word. What's matter is number of bits, or binary digits. You can say that byte is 2 bits and "word" is 3 bytes. That doesn't change anything, it's just groups of bits that has names.
But! 8086 processor had 20-bits external memory bus while internal registers were all 16-bits. To get 20 bits it combined special "segment" registers with address inside segment (shifted by 4 bits). That way they could address 1Mb.
So while processor might be 32 bits it may have 64-bits (or 48 or whatever) address bus. And OS and application (and I guess chipset) must be aware of that if they need to address memory beyond first 4 Gigs.
That's wrong. 8bit (1 byte) give you 2^8=256 "cells" of memory; 16 (2 bytes) 2^16 = 64K; 32 bits (4 bytes) is 4,294,967,296 (4Gb). It has nothing to do with number of bytes in word. What's matter is number of bits, or binary digits. You can say that byte is 2 bits and "word" is 3 bytes. That doesn't change anything, it's just groups of bits that has names.
Humor him. The more he thinks he's right the more work for people who understand what basic binary numbering means and how it applies to gate logic and higher abstractions.
4 (bytes/word)*2^32 would work if memory was word addressable. But you can address every 8 bits, not 32. Otherwise they would call it 4 Gwords. Or change meaning of "byte".
And a memory location is a byte, not a word. How big the word size is is irrelevant.
Actually that depends on the processor. Whether the processor is word addressable, byte addressable, or both are design decisions. A simple tutorial on the issue is available here: http://www.doc.ic.ac.uk/~phwl/teachi...tutorial1s.pdf
I've got a MacBook at the moment. 2.0ghz CoreDuo. I want to buy the new iMac when Leopard comes out so i'll have the Core2Duo with Leopard's 64 bit setup. Am I reading too much into this? How much faster will it actually be?
If the difference is minor then i'll probably use the cash for the touch! No iPhone in the UK yet
I'm confused about what everyone else is talking about, but let me break it down to you.
A processor can only process so much information during one clock cycle. How I learned it, it's like a jump rope. Everything moves during one cycle of the jump rope swinging, which is determined by the Hz of your computer, in which yours is 2,000 Hz, so 2,000 cycles per second.
Continuing with the analogy, "bits" are how many people are jumping at once. 8, 16, 32, 64, etc. This is what it means in computer terms. Every 8-bits = 1 byte. 1,000 bytes = 1 MegaByte etc. etc.
Everything in Binary would look like this for a 32 bit system:
"01011101 10011010 10011001 00110011"
That is how much information it can process per swing of the jump-rope. Now 64-bit would be exactly double the information being processed per jump rope swing. Does this mean your computer will run twice as fast? No, because not all information can be processed at 64-bit speeds., this is why Mac OSX has the ability to process both 32- and 64-bit applications. Mac OS9 bridged the gap between 16- and 32-bit systems.
Forget analogies. Computers aren't that complicated, fundamentally. The analogies are more complicated that the computers being described. If you're really curious, pick up an intro to comp arch textbook. Otherwise, just realize that, with all else equal, a 64 bit arch can move twice the the data of a 32 bit arch in the same amount of time. The downside is that instructions are also twice as long, so program size is bigger (but not 2x bigger -- figure that one yourself).
Since we use our PCs these days for media-rich tasks, and since media-rich datasets (images, video, audio) tend to be large and contiguous, 64 bit makes quite a difference.
Actually that depends on the processor. Whether the processor is word addressable, byte addressable, or both are design decisions. A simple tutorial on the issue is available here: http://www.doc.ic.ac.uk/~phwl/teachi...tutorial1s.pdf
Those are just set-piece test questions that have little bearing on modern reality. Once upon a time we worried about word addressing because there were mainframe architectures that had really odd length words, like 36 or 42 bit lengths. Those haven't been manufactured in volume since the early '70s. That prof just wants to see if his students can do the math, I do the same thing.
Since those early days we have found standardizing on byte addressable memory allows several orders of magnitude increases in performance since binary logic can be scaled well that way. It also meant a standard, consistent, best-practices based design methodology could be worked out. Now, all memory architectures of any note are byte addressable, word length is immaterial to addressing, but is important to cache management algorithms.
As to Archstudent's question, OS X on all OS X era Macs is capable of addressing the FULL 4GiB memory space per process. Without exception. Period.
There may be some confusion on physically installable memory in some machines. This is a slot and memory controller issue that constrains how much physical memory can be placed in the machine. Physical memory limits have absolutely no bearing on the addressable size of the address space under OS X's implementation of virtual memory. You can have a machine that can accept only 2 or 3GiB of RAM and still have a couple dozen processes all happily using their own full 4GiB memory spaces. That's the main benefit of virtual memory in the fist place, abstracting physical limitations away from logical software driven operations.
Actually that depends on the processor. Whether the processor is word addressable, byte addressable, or both are design decisions. A simple tutorial on the issue is available here: http://www.doc.ic.ac.uk/~phwl/teachi...tutorial1s.pdf
Thanks for the tutorial, but I have an Ivy League Masters in CS, as well as my MD, so I sort of already know that stuff.
64-bits isn't important to most people today. But it'll be essential tomorrow lest you want to have slow photo or movie editors once you start doing work on your 16 megapixel photos and your HD video or want to keep playing Unreal Tournament 200slow all your life.
but compiling leopard for 64-bit intel machines would imply, or at least allow, the use of other nifty features of the x86-64 architecture - no..?
(e.g. additional registers)
Yes, those registers technically aren't part of the 64-bitness though, they just got added at the same time. So when you talk about those extra registers it's better to talk about the chip revision to keep the two things straight. For the basic user though it's not an important distinction.
Even though the OS provides access to a certain size of address space, that address space can actually be larger than is supported by the underlying hardware. Throughout computing history this has frequently been the case.
The whole argument about how much ram is addressable by a 32 bit processor seems like a waste of time when discussed at the level of detail we're using here. Seems like it would be more productive to talk either about the bit-ness of the entire memory system or about the max memory capacity of specific computer models.
Even though the OS provides access to a certain size of address space, that address space can actually be larger than is supported by the underlying hardware. Throughout computing history this has frequently been the case.
Not frequently, constantly since the early 1960's when the concept of virtual memory was developed to a state that was workable. Even devices that don't use VM are affected by the same considerations.
Quote:
The whole argument about how much ram is addressable by a 32 bit processor seems like a waste of time when discussed at the level of detail we're using here. Seems like it would be more productive to talk either about the bit-ness of the entire memory system or about the max memory capacity of specific computer models.
The discussion is moot. There's one answer, 4GB per process. Carping beyond that at any level of detail with any other answer is a waste of time. And the installable amount of RAM currently doesn't even depend on the bitness or number of traces in the system. The installable amounts are all driven by the economics of what users can afford to put inside, more slots than that and it's wasted manufacturing cost.
You can put 32GB RAM in a Mac Pro if you want to drop a cool 5 grand+, very few users are going to need that, and most of those would probably prefer a second machine with 16GB in both instead, at an overall cost savings!
I don't feel like watching the "What's New In The Kernel" presentation again, but I seem to remember 47 bits as what the Leopard kernel offers. The kernel code itself is 32 bit and sequestered in low memory.
Leopard follows the standard LP64 model, 64-bit longs and pointers. There are new integer typedefs to make it easy to replace integer declarations in apps that you are moving to 64 bit.
Everything else, all of BSD, and all the Carbon and Cocoa frameworks, are 64 bit.
So you can release a bundle that has four binaries, and your machine will load the correct one at launch time.
sorry to be dense, but if I'm running parallels or vmware and want to install a windows app on my 2.4ghx c2d mbp, should I install the 32-bit or the 64-bit version of the software (in this case, ghostscript)? I assume it's the 32-bit, since I don't think I have a 64-bit capable version of WinXP installed.....
Comments
No, I am saying 4 (bytes/word)*2^32 words, which is 2^34 bytes.
That's wrong. 8bit (1 byte) give you 2^8=256 "cells" of memory; 16 (2 bytes) 2^16 = 64K; 32 bits (4 bytes) is 4,294,967,296 (4Gb). It has nothing to do with number of bytes in word. What's matter is number of bits, or binary digits. You can say that byte is 2 bits and "word" is 3 bytes. That doesn't change anything, it's just groups of bits that has names.
So while processor might be 32 bits it may have 64-bits (or 48 or whatever) address bus. And OS and application (and I guess chipset) must be aware of that if they need to address memory beyond first 4 Gigs.
That's wrong. 8bit (1 byte) give you 2^8=256 "cells" of memory; 16 (2 bytes) 2^16 = 64K; 32 bits (4 bytes) is 4,294,967,296 (4Gb). It has nothing to do with number of bytes in word. What's matter is number of bits, or binary digits. You can say that byte is 2 bits and "word" is 3 bytes. That doesn't change anything, it's just groups of bits that has names.
Humor him. The more he thinks he's right the more work for people who understand what basic binary numbering means and how it applies to gate logic and higher abstractions.
Byte addressing is not done in hardware, but, nonetheless, the system is byte addressable and memory is constrained thusly.
2^32 memory locations. Last time I checked, there were four (4) bytes in every 32-bit word. Perhaps things are different on your planet.
And a memory location is a byte, not a word. How big the word size is is irrelevant.
And a memory location is a byte, not a word. How big the word size is is irrelevant.
Actually that depends on the processor. Whether the processor is word addressable, byte addressable, or both are design decisions. A simple tutorial on the issue is available here: http://www.doc.ic.ac.uk/~phwl/teachi...tutorial1s.pdf
I've got a MacBook at the moment. 2.0ghz CoreDuo. I want to buy the new iMac when Leopard comes out so i'll have the Core2Duo with Leopard's 64 bit setup. Am I reading too much into this? How much faster will it actually be?
If the difference is minor then i'll probably use the cash for the touch! No iPhone in the UK yet
I'm confused about what everyone else is talking about, but let me break it down to you.
A processor can only process so much information during one clock cycle. How I learned it, it's like a jump rope. Everything moves during one cycle of the jump rope swinging, which is determined by the Hz of your computer, in which yours is 2,000 Hz, so 2,000 cycles per second.
Continuing with the analogy, "bits" are how many people are jumping at once. 8, 16, 32, 64, etc. This is what it means in computer terms. Every 8-bits = 1 byte. 1,000 bytes = 1 MegaByte etc. etc.
Everything in Binary would look like this for a 32 bit system:
"01011101 10011010 10011001 00110011"
That is how much information it can process per swing of the jump-rope. Now 64-bit would be exactly double the information being processed per jump rope swing. Does this mean your computer will run twice as fast? No, because not all information can be processed at 64-bit speeds., this is why Mac OSX has the ability to process both 32- and 64-bit applications. Mac OS9 bridged the gap between 16- and 32-bit systems.
Hope I got this right >_<
Hope I got this right >_<
Decent analogy... The only thing that really stuck out at me was that it's 2,000,000,000 Hz, not 2,000...
Since we use our PCs these days for media-rich tasks, and since media-rich datasets (images, video, audio) tend to be large and contiguous, 64 bit makes quite a difference.
Actually that depends on the processor. Whether the processor is word addressable, byte addressable, or both are design decisions. A simple tutorial on the issue is available here: http://www.doc.ic.ac.uk/~phwl/teachi...tutorial1s.pdf
Those are just set-piece test questions that have little bearing on modern reality. Once upon a time we worried about word addressing because there were mainframe architectures that had really odd length words, like 36 or 42 bit lengths. Those haven't been manufactured in volume since the early '70s. That prof just wants to see if his students can do the math, I do the same thing.
Since those early days we have found standardizing on byte addressable memory allows several orders of magnitude increases in performance since binary logic can be scaled well that way. It also meant a standard, consistent, best-practices based design methodology could be worked out. Now, all memory architectures of any note are byte addressable, word length is immaterial to addressing, but is important to cache management algorithms.
As to Archstudent's question, OS X on all OS X era Macs is capable of addressing the FULL 4GiB memory space per process. Without exception. Period.
There may be some confusion on physically installable memory in some machines. This is a slot and memory controller issue that constrains how much physical memory can be placed in the machine. Physical memory limits have absolutely no bearing on the addressable size of the address space under OS X's implementation of virtual memory. You can have a machine that can accept only 2 or 3GiB of RAM and still have a couple dozen processes all happily using their own full 4GiB memory spaces. That's the main benefit of virtual memory in the fist place, abstracting physical limitations away from logical software driven operations.
Actually that depends on the processor. Whether the processor is word addressable, byte addressable, or both are design decisions. A simple tutorial on the issue is available here: http://www.doc.ic.ac.uk/~phwl/teachi...tutorial1s.pdf
Thanks for the tutorial, but I have an Ivy League Masters in CS, as well as my MD, so I sort of already know that stuff.
(e.g. additional registers)
but compiling leopard for 64-bit intel machines would imply, or at least allow, the use of other nifty features of the x86-64 architecture - no..?
(e.g. additional registers)
Yes, those registers technically aren't part of the 64-bitness though, they just got added at the same time. So when you talk about those extra registers it's better to talk about the chip revision to keep the two things straight. For the basic user though it's not an important distinction.
The whole argument about how much ram is addressable by a 32 bit processor seems like a waste of time when discussed at the level of detail we're using here. Seems like it would be more productive to talk either about the bit-ness of the entire memory system or about the max memory capacity of specific computer models.
Even though the OS provides access to a certain size of address space, that address space can actually be larger than is supported by the underlying hardware. Throughout computing history this has frequently been the case.
Not frequently, constantly since the early 1960's when the concept of virtual memory was developed to a state that was workable. Even devices that don't use VM are affected by the same considerations.
The whole argument about how much ram is addressable by a 32 bit processor seems like a waste of time when discussed at the level of detail we're using here. Seems like it would be more productive to talk either about the bit-ness of the entire memory system or about the max memory capacity of specific computer models.
The discussion is moot. There's one answer, 4GB per process. Carping beyond that at any level of detail with any other answer is a waste of time. And the installable amount of RAM currently doesn't even depend on the bitness or number of traces in the system. The installable amounts are all driven by the economics of what users can afford to put inside, more slots than that and it's wasted manufacturing cost.
You can put 32GB RAM in a Mac Pro if you want to drop a cool 5 grand+, very few users are going to need that, and most of those would probably prefer a second machine with 16GB in both instead, at an overall cost savings!
Leopard follows the standard LP64 model, 64-bit longs and pointers. There are new integer typedefs to make it easy to replace integer declarations in apps that you are moving to 64 bit.
Everything else, all of BSD, and all the Carbon and Cocoa frameworks, are 64 bit.
So you can release a bundle that has four binaries, and your machine will load the correct one at launch time.
PPC 32 and 64
Intel 32 and 64
thanks,
gwr