13

The theoretical memory limits in 16, 32 and 64 bit machines are as follows:

  • 16 bit = 65, 536 bytes (64 Kilobytes)

  • 32 bit = 4, 294, 967, 295 bytes (4 Gigabytes)

  • 64 bit = 18, 446, 744, 073, 709, 551, 616 (16 Exabytes)

I remember from DOS / Windows 3.11 days, that 16 bit memory could be separated into segments, so that a 16 bit machine could access a greater amount of memory than 64 Kilobytes.

I have a machine with 16GB of memory, and am dual booting a 32bit operating system and a 64bit operating system. I can access all 16GB from 64bit, but only 3.21GB in 32bit.

So, my question is, if 16bit operating systems allowed greater that 64KB memory access due to memory segmenting, why do 32bit machines not follow the same pricipal?

12

They do, the system is called Physical Address Extension (PAE). Here is a list of windows OS'es and their max memory, any 32 bit system that allows for more than 4GB of RAM is using PAE to access the memory (For example Windows 2003 R2 Datacenter 32 bit allows for 128GB of ram).


In fact Windows 8 requires a PAE capable CPU in it's minimum requirements.


To address your "unasked" question on why your 32 bit OS can't access the ram if it exists: Licensing. They choose not to allow RAM to be above 4GB for their 32 bit OSes unless you pay for a data-center edition (that is why they sell a data-center edition, if you need that much ram, you likely can afford to spend more money on a OS).

  • Ah I've heard of PAE before but never investigated it. It appears to be largely used in server architecture, so does not seem to apply to a Windows 7 32bit installation, as the list specifies that W7x86 only allows up to 4GB – series0ne Feb 22 '13 at 22:09
  • 1
    @0xC0000022L to be fair, I added the license part as a edit after his comment, but due to the 4 min edit window it looks like I posted it before he posted the comment. – Scott Chamberlain Feb 22 '13 at 22:27
  • 1
    PAE requires page table switcheroo to work, and that is costly in terms of performance. – vonbrand Feb 23 '13 at 1:42
  • 3
    THat's a myth. The overhead due to PAE is tiny. And if you dislike PAE you should really hate x64, because the page table structure on x64 looks just like PAE, just with yet another table level added on top and more bits for PFNs in the PxE's. – Jamie Hanrahan Nov 7 '14 at 5:46
  • 1
    PAE was not "removed in Windows 7 because it is no longer needed", it is still present in Windows 7 x86 - it's just there by default rather than having to be optioned in. – Jamie Hanrahan Nov 7 '14 at 5:46
12

Instead of explaining it myself, I'll let someone who has to maintain a kernel with PAE support speak in his charming ways, Linus Torvalds

Also keep in mind that the PAE support in Windows 32bit versions comes for a lot of cash. XP won't even be able to make use of full 4 GiB of RAM normally, because MS chose to not enable PAE features on it. A kernel that is closely related, Windows 2003 Server, does support PAE. However, even there your "Standard edition" will only support up to 4 GiB (but working around the BIOS memory hole), whereas the more expensive editions will then allow up to 64 GiB of RAM. The same holds for 32-bit Vista.

However, not in all cases is this limitation imposed by Windows. If it were, booting a PAE-enabled Linux kernel would still enable you to use the full 4 GiB (or more). Not so, some hardware manufacturers chose to impose this limitation at the BIOS level, although the CPU and chipset would be capable of handling PAE.


Just a side-note: none of the current x86-based 64bit processors can even address the full range of the 64bit address space physically (for reference see this question and answers).

  • Very cool read in the link, thanks for it! – Scott Chamberlain Feb 22 '13 at 22:26
  • Hmm, why do I get the impression that Linus really hates HIGHMEM.SYS and PAE? :P – Karan Feb 24 '13 at 2:02
  • 2
    I understand that PAE would be a nuisance for any code which needed more than a couple gigs of working set, and for system-level code that needs to manage multiple tasks of 2 gigs or so each, but unless a single application needs more than 2 gigs I would expect PAE to be transparent. Further, I would think PAE would also be better than global use of 64-bit pointers in cases which needed 3 gigs of general-purpose RAM plus a large disk cache or temp-storage drive. – supercat May 6 '14 at 17:27
  • Linus's comments are strange. There is no relationship between how himem.sys works and how PAE works. It is very amusing to see people argue for x64 and against PAE addressing... when x64 long mode simply takes the PAE scheme and adds one more level of page table! – Jamie Hanrahan Aug 8 '14 at 21:21
  • @JamieHanrahan: ... at least two on newer systems (due to virtualization), which opens up some exciting possibilities. His (Linus') comparisons aren't completely right, but if it's a foreign concept, metaphors can help :) ... I guess that was why he chose it to make his point. – 0xC0000022L Aug 9 '14 at 0:58
1

Because there is no practical reason to do so. Physical Address Extensions allow much the same functionality and their use is still very limited amongst users. In the Windows 3.1 days there were constraints that just aren't present today.

  • 1
    This really does not have enough information to backup your statements. Windows 3.1 is a 16-bit operating system. One must remember that in 1992 2MB of memory was over $300. – Ramhound Feb 22 '13 at 23:26
  • You're Feb 22 comment, and Scott Chamberlin's explanation pretty much cover what I was driving at. They do leave out descriptions of why extensible segmented pagination was used in DOS/Win16, but not in later Windows. I didn't include that, because it would not contribute directly to answering the OP's question. – OCDtech Mar 7 '13 at 15:08
  • Its my view that answers should stand alone. Your comment adds enough information to resolve my problems with your answer. – Ramhound Mar 7 '13 at 15:51
  • 1
    @OCDtech: The 8086 segmented model would allow an object-oriented language to use 2-byte object references to identify objects aligned on 16-byte boundaries, but languages were not well-equipped to use segments effectively. The 80286 model imposes monstrously-greater overhead to such programs, and the way it was extended on the 80386 would make a segment-per-object scheme totally useless. – supercat May 6 '14 at 17:29
1

8-bit CPUs usually had a 16-bit address bus. (Motorola had a unified address bus, RAM and peripheral I/O shared the same address space, Intel chose to divide the two. In the case of Intel, the IO address limits of the 8088 and 8086 carried the limits over from the 8080 & 8085 CPUs.)

Intel's 8088 and 8086 had a 20-bit memory address bus(1MB), while Motorola's 68000 had a 24-bit address bus (16 MB). IIRC, the [80]286 jumped to a 24-bit address bus. Both later expanded to a 32-bit address bus with the [80]386 and the 68020 respectively.) With the Pentium chips, the address bus expanded to 64-bits. (I think the Motorola/IBM venture PowerPC chips also went 64-bit address bus.)

Memory available below and up to the maximum that could directly be accessed by the CPU was only limited by the supporting hardware chips (chipset) and OS. Bill Gates was famous in the past for stating that nobody needed more than 640K of RAM, thus DOS never evolved to directly access more RAM. With HiMem.sys and EMM386, DOS was extended to access more "upper" memory, with EMM386 being used to directly access all available RAM. HiMem.sys had less flexibility and could basically use the extra RAM for storage.

Memory exceeding that limit required a MMU (Memory Management Unit) to break the memory into segments and map it into the addressable memory space of the CPU. It's how the CoCo 3, Commodore 128, and other 8-bit computers could access more than 64K of RAM.

More favorable now is to use virtual memory to extend past physical memory limits, albeit with the limits imposed by the OS.

0

The theoretical memory limits in 16, 32 and 64 bit machines are as follows ...

The fundamental flaw here is the notion that the "bit width" of the processor, which is usually the size of the machine's general-purpose registers, is necessarily the same as the width of RAM addresses.

In x86 with paging enabled, but without PAE, the addresses that program and OS code use are called "linear addresses" by Intel - we usually call them "virtual addresses". They're 32 bits wide. This permits a 4 GiB virtual address space.

But it is more or less coincidence, merely an artifact of the format of page table entries that the size of a physical (RAM) address is also 32 bits.

With PAE the latter is 36 bits (at first... wider in later implementations). So, just because it is, for example, a "32 bit machine" does not mean that physical memory addresses are limited to 32 bits.

The industry has a long history of machines whose "bit width" did not match their maximum physical address size. For example, the VAX architecture defines a 32-bit machine, and virtual addresses (which are the addresses used by code once address translation is turned on) are indeed 32 bits wide... but the VAX's physical addresses are only 30 bits wide - and half of the physical address space is devoted to I/O device registers, so maximum RAM was only 512 MiB.

Even without address translation hardware, it is not necessarily the case that the machine's "bit width" defines the maximum RAM address. Example: The CDC "upper 3000" series were 36-bit machines. Do you think they could address 64 GiB of RAM? Not hardly! Those machines came out in the mid-60s! Heck, we couldn't even have 64 GB of disk space in those days. (The CDC 6000 series were 60-bit machines. Need I go on?)

  • And don't forget about systems that don't use 8-bits per RAM-cell. (EG: 16/16 = 128K max, 32/32 = 16G Max, 32/64=32G Max) – SkyCharger Feb 4 '17 at 2:09

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.