CODEWITHSUNDEEP
operating-systemcpucpu-architecturecpu-registers
eggachecat
eggachecat

Reputation: 111

Why do we need to "enter" 32-bit protected mode anyway?

Recently I've been interested in building an tiny-toy-OS from scratch, and I am really confused now. May you help me please..

The questions

I am getting stuck with understanding that why do we even bother to enter a 32-bit protected mode?

I mean why not just overwrite the old instructions from 16-bit into 32-bit (or 64-bit) so we can coding straightforward (e.g. accessing more memory addresses directly)... what's the point of this switching-process...why why why...

The reason why I am confused is that the tutorial I am reading first teaches me how to boot with 16-bit (some basic BIOS instructions) while it claims that "32-bit is better" which I totally agree and so we have to enter 32-bit protected mode. In my opinion this is just a simple extension of length of bits? why so different (tough to use BIOS, GDT, e-registers...)?

Upvotes: 1

Views: 1546

Answers (1)

Margaret Bloom
Margaret Bloom

Reputation: 44146

Intel has always tried to keep their CPUs backward compatible (and still is).
A new fancy CPU that can't run any existing software is as good as a rock for the industry.

The opcode b8 is mov ax, imm16, there are no other possible ways to interpret it, including mov eax, imm32, without breaking compatibility.
Unless you set a flag, somewhere, that let the CPU know it is OK to do so.
That's switching, and now b8 is mov eax, imm32.
So, the old instructions have been "overwritten" in a sense.

Intel could have used totally new opcodes but that'd be a huge waste of opcodes (and the opcode space was already very crowded at the time), plus going down this road and avoiding an explicit switch, the CPU would have to be both in real mode and in protected mode (since it cannot drop support for 16-bit code).
That's a call for very messy design or in the best a nightmare.

Peter Cordes pointed out that a prefix could be used if it weren't for the troubles with handling interrupts (and possibly any mechanism where the CPU performs automatic actions).

Protected mode come along with a new protection scheme, it's admittedly over-engineered but nevertheless, we need to deal with it, its GDT, IDT, TSS and so on.
This mechanism was set before the advent of 32-bit computing on the x86 architecture, i.e. it was present in the 286 when no 32-bit registers/addresses were present.
When Intel recognized the need for 32-bit computing it took the opportunity to ship it along with a revamped version of the protection scheme.

Whenever a new contract between the CPU and the software is developed, it always customary to require an explicit intention from the software, this prevents any spurious activation.

So switching provides:

  • An easier design.
  • A reuse of the opcodes (avoiding the need for prefixes).
  • A proof that the software is written to understand the new contract.
  • The same environment for the software that doesn't understand the new contract.

With the advent of UEFI, some constraints have been relaxed, a UEFI bootloader (or any application or driver) boots in 64-bit mode (or 32-bit if the CPU is too old for 64-bit).
If you feel unhappy with the legacy BIOS boot, you can experiment with UEFI.
Beware that 64-bit mode relies on everything that went before it, including protected mode and PAE paging.
You may get away with shoving them under the rug for some time, but if you plan to keep coding an OS, mastering the basics will pay off.

Upvotes: 2

Related Questions