linguofreak wrote:
What you find by debugging and single stepping may be behavior particular to the particular processor you're using, unless you can find something, unless you can find something in AMD's manuals that specifically says that a compatible x86-64 implementation will behave in exactly that way.
That particular processor is a (real) dual core AMD processor. I've learned to always trust reality rather than documentation if and when they conflict.
I'm sure my dual core Intel Atom processor behaves exactly the same way.
BTW, here is a reality-check for those that don't believe this to be the case:
1. Assume compability-mode is executing.
2. A hardware IRQ occurs, which causes a task-switch to whatever code
3. The task switcher code saves the segment registers of compability-mode somewhere
4. The task switcher later wants to switch back to compability-mode
5. The segment registers (for compability-mode) are reloaded in long mode.
6. Long mode does an ireq back to compability-mode
7. The bases and limits for the segment registers now are used again (because compability-mode should look like protected mode)
If the segment registers loaded in step 5 were not loaded with real bases & limits, the correct base and limit would not be in the selector caches in step 7 because iret doesn't restore general segment registers (DS, ES, FS, GS). In fact, there is no way compability-mode could be supported by the processor if segment loads in long mode didn't operate the same way as in protected mode. The processor actually also loads CS and SS bases and limits as it does the iret (which also happens in long mode).
And contrary to the initial information from AMD, it is possible to do far calls and returns both from long mode to compability-mode and from compability mode to long mode.