Intel’s CPUs have implemented a very good protected mode architecture since the 386 appeared in 1986. However, application programs cannot make use of protected mode all by themselves. The operating system must set up and manage a protected mode before application programs can run within it. MS-DOS couldn’t do this, and Microsoft Windows couldn’t really do it either until Windows NT first appeared in 1994. Linux, having no real-mode
‘‘legacy’’ issues to deal with, has operated in protected mode since its first appearance in 1992.
Protected mode assembly language programs may be written for both Linux and Windows releases from NT forward. (I exclude Windows 9xfor technical reasons. Its memory model is an odd proprietary hybrid of real mode and protected mode, and very difficult to completely understand—and now almost
102 Chapter 4 ■ Location, Location, Location
entirely irrelevant.) Note well that programs written for Windows need not be graphical in nature. The easiest way to program in protected mode under Windows is to createconsole applications, which are text-mode programs that run in a text-mode window called aconsole. The console is controlled through a command line almost identical to the one in MS-DOS. Console applications use protected mode flat model and are fairly straightforward compared to writing Windows GUI applications. The default mode for Linux is a text console, so it’s even easier to create assembly programs for Linux, and a lot more people appear to be doing it. The memory model is very much the same.
I’ve drawn the protected mode flat model in Figure 4-10. Your program sees a single block of memory addresses running from zero to a little over 4 gigabytes. Each address is a 32-bit quantity. All of the general-purpose registers are 32 bits in size, so one GP register can point to any location in the full 4GB address space. The instruction pointer is 32 bits in size as well, so EIP can indicate any machine instruction anywhere in the 4GB of memory.
The segment registers still exist, but they work in a radically different way.
Not only don’t you have to fool with them; youcan’t. The segment registers are now considered part of the operating system, and in almost all cases you can neither read nor change them directly. Their new job is to define where your 4GB memory space exists in physical or virtual memory. Physical memory may be much larger than 4GB, and currently 4GB of memory is not especially expensive. However, a 32-bit register can only express 4,294,967,296 different locations. If you have more than 4GB of memory in your computer, the operating system must arrange a 4GB region within memory, and your programs are limited to operating in this region. Defining where in your larger memory system this 4GB region falls is the job of the segment registers, and the operating system keeps them very close to its vest.
I won’t say a great deal about virtual memory in this book. It’s a system whereby a much larger memory space can be ‘‘mapped’’ onto disk storage, so that even with only 4GB of physical memory in your machine, the CPU can address a ‘‘virtual’’ memory space millions of bytes larger. Again, this is handled by the operating system, and handled in a way that is almost completely transparent to the software that you write.
It’s enough to understand that when your program runs, it receives a 4GB address space in which to play, and any 32-bit register can potentially address any of those 4 billion memory locations, all by itself. This is an oversimplification, especially for ordinary Intel-based desktop PCs. Not all of the 4GB is at your program’s disposal, and there are certain parts of the memory space that you can’t use or even look at. Unfortunately, the rules are specific to the operating system you’re running under, and I can’t generalize too far without specifying Linux or Windows NT or some other protected-mode OS.
But it’s worth taking a look back at Figure 4-8 and comparing real mode flat model to protected mode flat model. The main difference is that in real mode
Chapter 4 ■ Location, Location, Location 103 flat model, your program owns the full 64K of memory that the operating system hands it. In protected mode flat model, you are given a portion of 4GB of memory as your own, while other portions still belong to the operating system.
Apart from that, the similarities are striking: a general-purpose (GP) register canby itself specify any memory location in the full memory address space, and the segment registers are really the tools of the operating system—not you, the programmer. (Again, in protected mode flat model, a GP register can holdthe address of any location in its 4GB space, but attempting to actually read from or write to certain locations will be forbidden by the OS and trigger a runtime error.) a new job now. They locate your 4 GB “flat” segment in system virtual memory.
The OS won’t let you fool with them! They’re to be executed by the CPU.
4 GB
Figure 4-10: Protected mode flat model
104 Chapter 4 ■ Location, Location, Location
Note that we haven’t really talked about machine instructions in detail yet, and we’ve been able to pretty crisply define the universe in which machine instructions exist and work. Memory addressing and registers are key in this business. If you know them, the instructions will be a snap. If you don’t know them, the instructions won’t do you any good!
What difficulty exists in programming for protected mode flat model lies in understanding the operating system, its requirements, and its restrictions. This can be a substantial amount of learning: Windows NT and Linux are major operating systems that can take years of study to understand well. I’m going to introduce you to protected mode assembly programming in flat model in this book, but you’re going to have to learn the operating system on your own.
This book is only the beginning—there’s a long road out there to be walked, and you’re barely off the curb.