HailMary, I see what you mean. There is a fine (but important) distinction that needs to be made. In Compatibility Mode, binary 32-bit applications have to work unmodified. This means they can specify segments (and segment overrides) just as if they were running on a 386 - just as if they were running with a legacy LDT controlling their behavior. That is what is meant by the section you quoted:
In long mode, the effects of segmentation depend on whether the processor is running in compatibility mode or 64-bit mode:
- In compatibility mode, segmentation functions just as it does in legacy mode, using legacy 16-bit or 32-bit protected mode semantics.
- 64-bit mode, segmentation is disabled, creating a flat 64-bit virtual-address space. As will be seen, certain functions of some segment registers, particularly the system-segment registers, continue to be used in 64-bit mode.
However, this is smoke & mirrors for the application's sake. In Compatibility Mode, the legacy segment structures don't really exist, they are emulated for the application (Volume 1, p.9):
As with 64-bit mode, compatibility mode is enabled by the operating system on an individual code-segment basis. Unlike 64-bit mode, however, x86 segmentation functions the same as in the legacy x86 architecture, using 16-bit or 32-bit protectedmode semantics. From the application viewpoint, compatibility mode looks like the legacy x86 protected-mode environment. From the operating-system viewpoint, however, address translation, interrupt and exception handling, and system data structures use the 64-bit long-mode mechanisms.
Another important point is that the true segmented modes - Real Mode and Virtual 8086 Mode - are not supported at all in Compatibility Mode (Volume 1, p.8):
Long mode does not support legacy real mode or legacy virtual-8086 mode, and it does not support hardware task switching.
Now, some aspects of segmentation must continue to exist - even in 64-bit mode - because there is quite a bit of goodness contained therein. All contemporary processors provide this in one way or another. Such features include:
1. Zero-based addressing for multiple applications located in different parts of actual memory;
2. Memory protection for areas designated as data, stack or code (actually, AMD64 has an improved protection to prevent overflow viruses).
3. Memory protection so that each application can not accidently corrupt the contents of another application's space.
Contemporary architectures have to employ a concept of a starting point for application addressing, and a limit for allocated space. These are protections afforded by the simplified segmentation aspects in AMD64.
When programmers complained about segment problems, it generally referred to situations where the program is larger than the largest segment available. This was common in 8086 and 80286 systems. This meant that compilers specified segments for all their data accesses, which made the compiled code both larger and slower. Every data reference had a segment reference attached, and it was loaded into a segment registered before the address could be used. Very inefficient! 386 32-bit flat addressing solved this problem but every Intel processor kept all the old stuff that AMD nows partitions and isolates.
I hope this explanation enlightens more than it confuses. :)
News 
Market Data 
Discover 
