2

Until now I thought that a 32-bit processor can use 4 GiB of memory because 232 is 4 GiB, but this approach means processor have word size = 1 byte. So a process with 32-bit program counter can address 232 different memory words and hence we have 4 GiB.

But if a processor has word size larger than 1 byte, which is the case with most of processors now days I believe (My understanding is that word size is equal to the width of data bus, so a processor with 64-bit data bus must have a word size = 8 bytes).

Now same processor with 32 bit Program counter can address 2^32 different memory words, but in this case word size is 8 bytes hence it can address more memory which contradicts with 4 GiB thing, so what is wrong in my argument ?

phuclv
  • 37,963
  • 15
  • 156
  • 475
mightyWOZ
  • 7,946
  • 3
  • 29
  • 46
  • 32-bit processors are _not_ limited to using 4 GiB of memory, your whole premise is incorrect. – davmac Nov 07 '15 at 12:22
  • so does that mean 32 bit processors can use any amount of memory – mightyWOZ Nov 07 '15 at 13:00
  • 1
    no, it means a 32-bit processor can use however much memory that particular 32-bit processor can use. There's more than one 32-bit processor, you see. – davmac Nov 07 '15 at 13:28
  • say i made a 32 bit processor with 32 bit program counter, than how much memory it can address? – mightyWOZ Nov 07 '15 at 13:57
  • 1
    @Balraj 4GB per single _process_, but it could be more for the whole PC (that's how x86 PAE works). Another option is _bigger_ counter, say, 40-bit as in LPAE in ARM-32. And so on. – Matt Nov 07 '15 at 14:13
  • 2
    @Balraj a 32-bit program counter can address 2^32 locations (of unspecified size). – davmac Nov 07 '15 at 16:11
  • @Balraj (but that assumes there's no additional component in the resolution of the address. x86 for instance allows the code segment to be located at different virtual addresses, up to a size larger than 4GB, which is the normal addressable range of the x86 PC). – davmac Nov 08 '15 at 15:23

2 Answers2

2

CPU (at least x86 family 32-bit) must be able to access any byte/word/dword in 4GB space. So an instruction is encoded such a way that target word size and memory address (usually) belong to different bit-fields. So it doesn't matter whether CPU accesses byte or dword, but the encoded memory address must be the same.

Note that 32-bit OS and x86 CPU technically is able to acccess more than 4GB address space using PAE mode. But it is not supported by, say, the current Windows OS family (except Server editions). Some versions of WinXP, as well as Linux and other 32-bit OS can address 64GB of memory on x86 CPU.

Also, usually OS reserves some part of virtual address space (for OS kernel, Video memory etc.), so user programs may use, say, no more than 3 GB of RAM of the 4GB an OS can address within each process.

Community
  • 1
  • 1
Matt
  • 13,674
  • 1
  • 18
  • 27
2

Your premise is incorrect. 32-bit architectures can address more than 4GB of memory, just like most (if not all) 8-bit microcontrollers can use more than 256 bytes of memory. Indeed a 32-bit program counter can address 232 different memory locations, but word-addressable memory is only used in architectures for very special purposes like DSPs or antique architectures in the past. Modern architectures for general computing all use byte-addressable memory

See Why byte-addressable memory and not 4-byte-addressable memory?

Even in 32-bit byte-addressable architectures there are many ways to access more than 4GB of memory. For example 64-bit JVM can address 32GB of memory with 32-bit pointer using compressed Oops. See the Trick behind JVM's compressed Oops

32-bit x86 CPUs can also address 64GB (or more in later versions) of memory with PAE. It basically adds a another level of indirection in the TLB with a few more bits in the address. That allows the whole system to access more than 4GB of memory. However the pointers in applications are still 32-bit long so each process is still limited to 4GB at most. The analog on ARM is LPAE.

The 4GB address space of each process is often split into user and kernel space (before Meltdown), hence limited the user memory even more. There are several ways to workaround this

  • Spawning multiple processes, which is used in Adobe Premiere CS4
  • Mapping the needed part of memory into the current address space, like Address Windowing Extensions on Windows
  • ...
phuclv
  • 37,963
  • 15
  • 156
  • 475