On Wed, Aug 2, 2017 at 1:38 PM Philipp Stanner stanner@posteo.de wrote:
Dear Patrick, dear Zoran & List,
thank you, this was *very* helpful. I had some misunderstandings regarding function and features of the CPU-modes.
Let me sum it up again and feel free to correct further mistakes.
- 16-Bit-Real Mode: No virtual memory, no segmentation. 2^20 addresses
of memory.
and really dumb segmentation to get that 20 bits: 16 bit segment, 16 bit offset, 20 bit address from (seg << 4) + offset
So a given address in real mode can be created many, many different ways: f000:ffff0 and ffff:0 are the same address. The horror. I saw a talk once by the inventor of this mess and he was actually proud of it. Go figure.
- Protected Mode (flat mode?): CPU is in Protected Mode, Paging is
off. The primary difference to Real Mode is that 2^32 Bytes of memory are available. Coreboot + Payloads use this mode, because they need >1MiB of memory due to various reasons
And we want the 32-bit instruction set. Also, flat is not really the right word. You can have a segment descriptor that has a built in offset and a built in limit such that, e.g., you can only address 20 bits of the 32 bit address space starting at, e.g., 0x2000. I think you would find a reading of how the descriptors work very interesting.
Addresses in protected mode are virtual addresses, and are mapped to physical addresses as determined by the segment used.
- Virtual Mode: Paging is on, the MMU is on. Memory can only be
accessed by using virtual addresses. Details are specified in the GDT.
no. The GDT is about segments, i.e. protected mode. I don't like the word virtual here unless you want to say virtual address. When I've used the word virtual before on the list, I've gotten in trouble, because people associate virtual memory with swapping pages to a disk. Just call it paged mode and there's less confusion.
- Long Mode: Paged virtual 64-Bit mode. Standard mode of modern
operating systems (while I presume Protected Virtual Mode is the Standard for any OS on i386)
pretty much.
thanks
ron