Sign in with
Sign up | Sign in
Your question
Solved

Technical reasons behind 32-bit(x86) memory limit

Last response: in Memory
Share
April 6, 2013 10:21:35 PM

I have been looking into the limit and heard more different things and would like to just get the facts straight.
So
How does GiB fit into it and how do they relate to GB and Gb?

It was the hardware and not the OS technically that caused the limit. Because in the past 32-bit (x86) processors could not physically process more than 4 Gib of memory. However these days pretty much all CPU's are 64-bit with the ability to conform to 32-bit, so they can actually process more ram without issue, even when running 32-bit OS. So the actual limit when running a 32-bit OS comes from code running in the OS that says that no-more can be used. Presumably this is for backwards compatibility, so if you were to use a 32-bit processor for whatever reason there would be no issue. However you can bypass the code restriction in windows 32-bit to use more than the limit, assuming you have a x64 processor you are good to go. this is due to the fact that when running on 64-bit CPU, you get the same memory interface no matter if you are running 32bit or 64bit code ( as you are using the same cache and same BUS).

Is this correct? That is what i have managed to gather so far, but would really like to understand the technical side so i have a fuller understanding

Thanks

Best solution

April 7, 2013 2:15:03 AM

Each byte of memory has a unique address. 32-bit software limits memory addressing to 32-bits (4 bytes). This results in 2^32 = 4,294,967,296 bytes of addressable memory, which is 4 GB. In PCs it's a bit less than that due to 1 MB being reserved for archaic reasons. If you have integrated graphics, it will usually reserve 16-256 MB of memory for itself to use as video RAM.

The "limitation" stems from having the CPU address memory in the quickest way possible. A 32-bit CPU can only process a maximum 32-bit number with one instruction. Processing a bigger number (like a 64-bit float) requires 2 instructions. Likewise, addressing memory addresses bigger than the CPU can process requires 2 instructions, and can result in software running as slow as half the speed the CPU is capable of.

So no it's not really a hard limit; merely one imposed in order to keep the computer speedy. It's possible to write the OS so it can address more memory than the bit limit. This was done with 8-bit and 16-bit CPUs (256 byte and 64 kB limit respectively) because the memory amounts they could address directly were so limited, even at the time. On the x86 processors this was done by segmenting memory. The address space was broken up into two numbers: a segment and an offset. This effectively squared the number of bytes of memory the CPU could address. So a 16-bit CPU with segmented memory could theoretically address 4 GB of memory (16-bit segment address, 16-bit offset address).

In practice I think the way it worked was that the CPU was set to a segment, and only used offsets to address memory until it was told to switch to a different segment. That meant a single program was still limited by the 8-bit or 16-bit memory limit, but it would run at full speed within that limit. (BTW this was a major PITA when writing big programs. My recollection is a bit hazy because I've done my best to forget all the headaches it caused.)

When computers started to hit the 4 GB memory limit, Intel/AMD decided it would be easier simply to transition to 64-bit CPUs and maintain flat memory addrssing, instead of resorting to a segmented memory scheme like had been done in the past. As someone who pulled a lot of hair out programming around memory segments, trust me - this was a wise decision. 32-bit OSes still run a 64-bit CPU in 32-bit compatibility mode, so still suffer from the 4 GB limit.

There are ways to get 32-bit Windows to address memory beyond 4 GB, but because of the prevalence of 64-bit Windows none that I've tried have been rock solid stable nor easy to set up. It's easier just to reformat and install 64-bit Windows.

GiB is something foisted onto the computer industry by the folks who like round numbers. Originally, with respect to computers, kB, MB, and GB were 2^10, 2^20, and 2^30 respectively. But those result in non-round numbers (1024, 1,048,576, and 1,073,741,824). Hard drive manufacturers were the first to break with this convention because some wise-ass marketer realized if he did, he could label a 190 MB drive as 200 MB and make more money by tricking people into buying a smaller drive than their competitors'. I think it was Maxtor that did it first. IBM was the last holdout who finally gave in about 7 years later and switched to MB = 1,000,000 bytes on their hard drive labels. Since then it's mostly been metric system purists who insist that the computer industry use MB = 1 million, GB = 1 billion.

Unfortunately that definition doesn't work so well for computers. Even if you label things according to powers of 10, computers still work in powers of 2. So you can't make a 1 billion byte memory module (well you could, but it would end up either wasting perfectly good memory, or your addressing would arbitrarily come to an abrupt hole). So things like memory and disk space as reported by the OS are still given in terms of GB = 1,073,741,824 bytes. Some people proposed that this be called 1 GiB instead to avoid confusion with the 1 GB = 1 billion bytes definition, but it hasn't been widely adopted.

Gb (and Mb, kb) refers to gigabits. Lowercase b = bits, uppercase B = bytes.
Share
April 7, 2013 5:34:17 AM

Thanks, it is good to get a response from somebody that really knows what they are talking about! I appreciate it

m
0
l
Related resources
April 7, 2013 7:26:07 PM

Solandri said:


So no it's not really a hard limit; merely one imposed in order to keep the computer speedy. It's possible to write the OS so it can address more memory than the bit limit. This was done with 8-bit and 16-bit CPUs (256 byte and 64 kB limit respectively) because the memory amounts they could address directly were so limited, even at the time. On the x86 processors this was done by segmenting memory. The address space was broken up into two numbers: a segment and an offset. This effectively squared the number of bytes of memory the CPU could address. So a 16-bit CPU with segmented memory could theoretically address 4 GB of memory (16-bit segment address, 16-bit offset address).

In practice I think the way it worked was that the CPU was set to a segment, and only used offsets to address memory until it was told to switch to a different segment. That meant a single program was still limited by the 8-bit or 16-bit memory limit, but it would run at full speed within that limit. (BTW this was a major PITA when writing big programs. My recollection is a bit hazy because I've done my best to forget all the headaches it caused.)


I have one question, you seemed to say that even if an OS allows the computer to access more RAM than normal, eg with a 32-bit processor, a single program can not access more than the normal amount eg 4GB
So does the OS, eg windows count as a program or do programs effectively run separately just using the OS as an interface, also does that mean that effectively there will be no slow down as there is no more than one pass? With the only restriction being 4 GB for each program. Also say you have 8GB of ram, can one programs use one lot of 4 GB and the other program use the other 4 GB lot

Thanks for you time!
m
0
l
April 12, 2013 7:35:44 PM

You'll have to talk to a compiler author or assembly programmer to answer that. I can only tell you how it impacted writing higher level software in C/C++. In the 16-bit days, with 64 kB segments, you had to pick which memory model you used for your program when compiling. Stuff that could all fit in 64 kB was easy. For bigger programs, you had a choice of memory models to use depending on the size of the program vs. data. The compiler and CPU would then do its voodoo magic to juggle memory around so your program could access all of it as quickly as possible.

As for what was happening on the silicon level, I don't know. The wiki articles have all the gory details if you really want to know.
http://en.wikipedia.org/wiki/Memory_segmentation
http://en.wikipedia.org/wiki/X86_memory_segmentation

If you're currently in a situation with 32-bit Windows and >4 GB memory, here's the wiki for the Intel feature to access memory above 4 GB. As well as one of the RAMDisk apps available which utilize that extra memory. As I said, I was never able to get it to work reliably, but that was about 5 years ago.
http://en.wikipedia.org/wiki/Physical_Address_Extension
http://blog.raxco.com/2012/12/03/how-to-solve-the-32-bi...
m
0
l
!