Conceded. I'm skipping steps when I speak.
GAMES will not likely be utilizing more than 8 GB of RAM in the foreseeable future, and that is basically down to games being built for 32 bit systems as well as 64. 64 bit processing is capable of using up way more RAM than anyone has on a desktop nowadays (stereotypically speaking: 8-16 GB). 32 bit systems may use only 4 GB of RAM maximum because of 32 bit processing limits within Windows. Linux systems and 64 bit processing systems have already tipped the balance toward more, but developers need to actually be able to write programs that run in real-time with all of the detail possible for capable systems to take advantage of it. That has not happened yet as far as I know.
It won't likely happen much even in the next 5 years or so. When you up the amount of RAM used, the game grows exponentially -- in both detail and calculations-per-second. We'll see it someday, sure! Just not next week.
The common register (or uncommon since IA-64 and X86-64 (both intel and AMD versions of it) support just as many 128bit registers as they do 64bit registers mainly for SIMD operations) size and word size supported by the CPU has nothing to do with the memory address space it supports.
All Pentium IA-32 Intel CPU's have had 36 bit memory address space to support PAE and used 36 bit memory address registers(MAR's).
The funny part is that technically there isn't a 64bit memory address space available on any operating system...
When AMD was working on AMD64 they've settled on a 48bit Virtual Address Space, and a 52bit physical address space (with probably no reasonable justification as to why).
Intel when building EMT64 decided that if AMD is using PAE now too they'll rename their memory management architecture IA-32e which provides either 32bit address space in protected (not to be confused with actual protected vs real mode CPU operations, because terminology...) mode (32bit/mixed mode) or 64bit when running in IA-32e mode (which is was Intel calls a native 64bit mode because again terminology)
Microsoft on the other hand said hmmpf, 32, 36, 48, 64, 80, k we are supporting 44 bit address space and nothing more.
Linux well who knows atm i think 4 supported 38... really depends on which kernel you use currently but again no full 64bit memory address space either.
Operating systems even 32bit ones may use much more than 4GB of ram with any processor which supports virtual memory addressing and has a dedicated MMU to provide address translations, not going to waste about 5 pages explaining this but please read about segmentation, memory allocation, virtual memory addressing and just in general about how memory is being handled on operating systems and hardware since about 1982(80286!!!)...
If that's too much at least just get an understanding of the difference between the physical address space, virtual address space, window size and image size and then google how Address Windowing Extensions work.
The physical limit of memory in NT based Windows operating system is for the most part license based, a 32bit Windows 2003 Server (Enterprise and above) will support 64GB how? because with 36 bit MAR's you got 68719476736 bytes of address space available which is 64 gigbytes, on Windows 2003 Datacentre edition with more than 1 physical CPU the limit can be even higher.
On the other hand a 64bit version of Windows 7 Home Premium (which is the most common SKU of the currently most common Windows OS distribution) only supports 16GB of physical memory, why? because if you can afford or need more than 16GB of RAM you can afford to pay for the pro version.
Not really. The only reason 32 bit is still widespread is mostly because of many mobile ARM CPUs which only now are starting to switch to 64 bit arch. That's happening however, so quite soon 32 bit will be practically obsolete.
You can already see new games coming out in 64 bit only. It's easier to develop, and developers don't need to deal with all the mess involved with supporting 32 bit. So it's not just next week - it's already now.
Nothing to do with ARM or mobile, ARM's 64bit implementation is also nothing like the x86-64 implementation (it will have something of linear length of 64bits some where but that's where the commonality ends), not to mention that your compiler handles target translation and optimization any how , if you'll use anything say from the Intel standard library or STL which is platform specific like in example TBB your code is incompatible no matter if the target CPU is "bit compatible" or not and no compiler will save you.
And as far as memory limit goes then ARM V8 and it's future offspring use 32bit (LPAE limit) virtual memory addressing and 40bit physical memory address.
Which means that even with 64bit ARM CPU's you won't be able to allocate more than 4GB of memory for each application as the max window size is limited by the 32bit address space.
The amount of actual available memory is going to be even lower depending on the operating system the default settings for Windows is that either the 2 or 3 lower GB (depending if 4GT is on or off) of every virtual address space are available for each user space process with the upper 2 or 1GB being mapped to the kernel.
Android memory management is completely fubar atm and is really dependent on if you are using dalvik, ART or are building your apps through the NDK.
And I'm not even going to bother guessing what the hell Apple is doing with IOS these days...