HailMary, let's conclude this here as a new work week is upon us. :)
Thank you for pulling out those quotes from Vol. 2. I am taking a fresh look at the diagram on p. 7. We've reached the point where our interpretations differ more in semantics than fact: I stated that, in Compatibility Mode, the processor puts an emulation layer on top of the 64-bit flat mode addressing. I also agree that it has to fully implement a Protected Mode environment to guarentee binary compatibility for 32-bit applications.
You found a number of good quotes which show that, indeed, the application sees something that looks just like Protected Mode. I agree fully.
Let's look at the chart on p. 7, Vol. 2. It shows how the system translates from segement registers to flat addressing. The emulation does contain a descriptor table (at one point I did post otherwise, I will correct myself here); the text on p. 6 confirms this structure is used for both legacy and compatibility segments. In 64-bit mode this structure is not employed, the effective address is used directly, as shown on p. 8. P. 9 shows how the effective (or virtual) address translates into a physical address by using page translation tables.
Here is where this is all leading:
1. I concur that Compatibility Mode has to fully support Protected Mode-style segementation.
2. The emulation works as follows: 32-bit (and 16-bit, if supported by OS) apps go through an emulation layer which uses a descriptor table to translate the segmented address to a virtual address.
3. Compatibility Mode differs from Legacy Mode in this way: In Legacy Mode, the virtual address is the physical address. In Compatibility Mode, the virtual address is then put through the 64-bit logic of paged memory to convert to a physical address. This is what I mean by 'emulation layer' - the underlying processor mechanism is the paged memory system, the segmented memory is converted first into a virtual address fed through the 64-bit logic.
Why is this significant? In Long Mode, segmentation exists for Compatibility Mode as a pre-processor to the page table method of resolving addresses. This means the segmentation logic is functionally separated from the underlying memory logic, and can be discarded easily in some future system made only for 64-bit applications.
That is my point: Segmentation in K8 is functionally separate from the 64-bit architecture in a way such that it can be jettisoned later. First, Legacy Mode can be removed. Second, Compatibility Mode can be removed (although this will take a number of years). Then segmentation is gone. This process is gated by software: Legacy mode can go as soon as 64-bit OSs are commonly available. Compatibility mode can go when all the useful applications are available in 64-bit.
Then the hardware will have no segmentation at all.
