Assembly Segmented Model 32bit Memory Limit

If a 32bit Operating System operated with a segmented memory model would their still be a 4GB limit?

I was reading the Intel Pentium Processor Family Developer's Manual and it states that with a Segmented memory model that it is possible map up to 64TB of memory.

"In a segmented model of memory organization, the logical address space consists of as many as 16,383 segments of up to 4 gigabytes each, or a total as large as 2^46 bytes (64 terabytes). The processor maps this 64 terabyte logical address space onto the physical address space by the address translation mechanism described in Chapter 11. Application programmers can ignore the details of this mapping. The advantage of the segmented model is that offsets within each address space are separately checked and access to each segment can be individually controlled.

This is not a complex question. I just want to be sure I understood the text correctly. If Windows or any other OS worked in a segmented model rather than a flat model would the memory limit be 64TB?

---

Update:

Intel's 3-2 3a System Documentation.

---

http://pdos.csail.mit.edu/6.828/2005/readings/i386/c05.htm

---

The Segment Register should NOT be thought as in the traditional Real-Mode sense. The Segment Register acts as a SELECTOR for the Global Descriptor Table.

In Protected mode you use a logic开发者_开发技巧al address in the form A:B to address memory. As in Real Mode, A is the segment part and B is the offset within that segment. The registers in > protected mode are limited to 32 bits. 32 bits can represent any integer between 0 and 4Gb. Because B can be any value between 0 and 4Gb our segments now have a maximum size of 4Gb (Same reasoning as in real-mode). Now for the difference. In protected mode A is not an absolute value for the segment. In protected mode A is a selector. A selector represents an offset into a system table called the Global Descriptor Table (GDT). The GDT contains a list of descriptors. Each of these descriptors contains information that describes the characteristics of a segment.

The Segment Selector provides additional security that cannot be achieved with paging.

Both of these methods [Segmentation and Paging]have their advantages, but paging is much better. Segmentation is, although still usable, fast becoming obsolete as a method of memory protection and virtual memory. In fact, the x86-64 architecture requires a flat memory model (one segment with a base of 0 and a limit of 0xFFFFFFFF) for some of it's instructions to operate properly.

Segmentation is, however, totally in-built into the x86 architecture. It's impossible to get around it. So here we're going to show you how to set up your own Global Descriptor Table - a list of segment descriptors.

As mentioned before, we're going to try and set up a flat memory model. The segment's window should start at 0x00000000 and extend to 0xFFFFFFFF (the end of memory). However, there is one thing that segmentation can do that paging can't, and that's set the ring level.

-http://www.jamesmolloy.co.uk/tutorial_html/4.-The%20GDT%20and%20IDT.html

A GDT for example lists the various users their access levels and the areas of memory access:

Sample GDT Table

GDT[0] = {.base=0, .limit=0, .type=0};             
// Selector 0x00 cannot be used
GDT[1] = {.base=0, .limit=0xffffffff, .type=0x9A}; 
// Selector 0x08 will be our code
GDT[2] = {.base=0, .limit=0xffffffff, .type=0x92}; 
// Selector 0x10 will be our data
GDT[3] = {.base=&myTss, .limit=sizeof(myTss), .type=0x89}; 
// You can use LTR(0x18)

http://wiki.osdev.org/GDT_Tutorial#What_should_i_put_in_my_GDT.3F

The Paging portion is what maps to physical memory. (PAE) is what provides addtional memory up to 64GB.

So in short. The answer is no you cannot have more than 4GB of logical memory. I consider the claim for 64TB a misprint in the Intel Pentium Processor Family Developer's Manual.

---

Edit: My answer assumes that by "4GB limit" you are referring to the maximum size of linear (virtual) address space, rather than of physical address space. As explained in the comments below, the latter is not actually limited to 4GB at all - even when using a flat memory model.

---

Repeating your quote, with emphasis:

the logical address space consists of as many as 16,383 segments of up to 4 gigabytes each

Now, quoting from "Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 1: Basic Architecture" (PDF available here):

Internally, all the segments that are defined for a system are mapped into the processor’s linear address space.

It is this linear address space which (on 32-bit processor) is limited to 4GB. So, a segmented memory model would still be subject to the limit.

---

Do you remember the old days? DOS on x86 in real mode with 64kb segments? FAR pointers? HMA? XMS? As the amount of memory grew, they've found ways to use more memory than processor could normally address. But it was ugly.

Sure they could use segmentation for 32 bits, but why? There was no need. When 32 bit processors appeared the 4Gb limit was more than enough, so the decision to use flat model was made.

Also, a 32bit OS can use more than 4Gb, it's the process that is limited to 4Gb address space (even 2 or 3 on windows).

---

The claim is 64TB of logical address space. Bringing up physical memory limitations is irrelevant because by enabling memory paging, one can bypass the physical limitations.

However, this is still a slightly misleading claim because the the Index field of the Segment Selector is 16 bits, minus 1 bit for Table Indicator and 2 bits for Request Protection Level, leaving a total of 8,192 (13 bits) segments selectors. With 8,192 4GB segments one could only have access to 32TB of logical memory in either the GDT(Global Descriptor Table) or the LDT (Local Descriptor Table). To be able to access 64TB of logical memory, one would have to fully utilize both the GDT and LDT with 16,384 unique segments.

Regardless, the first question was, "is there a 4GB limit", and the answer is, "no". On a 32-bit system with both Segmentation and Paging enabled, one could, for example, allocate 512MB to the Code Segment(CS), 1GB to the Stack Segment(SS), and 4GB to the Data Segment(DS).

The answer to the second question of whether the OS would be limited to 64TB if it used a segmented memory model is less straight forward. It is the job of the OS to provide the memory manager. Obviously there would be a physical limitation of 32GB of RAM. 32-bit Linux, because it uses paging, can provide each application with a 4GB flat address space (ignoring the kernel/user split details). And, every process believes it has 4GB of physical address space.

In short summary, I think you are confusing the limitations of segmentation with the limitations of paging. Paging enables a system or application to use more RAM than what is physically available. Segmentation enables a process to map in multiple 32-bit logically addressable segments. Its key to note that even flat mode uses segmentation, but all segment registers are mapped to the same base address.

---

AFAIK, the answer is 'not necessarily', due to other limitations of the OS. They may want to keep the maximum size of memory down well below the theoretical limit, because this could make some of the internal memory structures smaller and more performant. But I really don't know... I'm no Mark Russinovich...

Take a look at PAE. I think this is what you're talking about, but since I've graduated to 64-bit pointers, I've decided to kill the brain cells which dealt with windowing memory models with Kentucky Straight Bourbon Whiskey.

---

The Intel's segmented model is limited to 16,384 segments. That is too small a number to really make things convenient. What would have been much nicer would have been if the system could quickly switch among two or four billion segments. That's what I would have liked to have seen, rather than a 64-bit linear space. A design that could efficiently put each allocated object into a different segment would allow for no-extra-overhead range checking on every individual allocated object, object relocation with minimal impact on running code (assuming the CPU could notice when a currently-selected segment was invalidated), etc. while only requiring object references to take half as much space in the cache as a 64-bit pointer.