OSDev.org

There is something, I really can't understand:

Real Mode is 16-Bit mode.
Protected Mode is 32-Bit mode.

OK! Then why the code to enter pmode is this:
When we are in real mode, which is 16 bit mode...I don't get it!

When we want to use a 32-bit general-purpose register or a 32-bit address but still in real mode,a prefix is added to the requiring instruction.But this will only work for 80386+ machines.

INF1n1t wrote:There is something, I really can't understand:

Real Mode is 16-Bit mode.
Protected Mode is 32-Bit mode.

OK! Then why the code to enter pmode is this:

Code: Select all

 mov eax, cr0
 or al, 1
 mov cr0, eax

When we are in real mode, which is 16 bit mode...I don't get it!

There is nothing particularly 16 bit-ish about real mode. It is just that MS-DOS was a 16 bit operating system, and the early 16 bit processors from Intel ran exclusively real mode.

A 32 bit version of MS-DOS, running in real mode, and able to address more than 1mb of memory, would be technically possible. It was even written, and would have been version 4, had it been released. But version 3.4 was released as version 4 instead. (Because Microsoft did not want it competing with OS/2, which they were at the time sponsoring.)

INF1n1t wrote:There is something, I really can't understand:

Real Mode is 16-Bit mode.
Protected Mode is 32-Bit mode.

OK! Then why the code to enter pmode is this:

Code: Select all

 mov eax, cr0
 or al, 1
 mov cr0, eax

When we are in real mode, which is 16 bit mode...I don't get it!

Yes, 16-bit rmode just means the default operation is 16-bits, you can do 32-bit operations, but each instruction will have a 0x66 prefix added to it to denote that it is a 32-bit instruction while in 16-bit mode. All 3 of those instructions assume 16-bit mode, but the next instruction after the mov cr0, eax will assume 32-bit mode, so it will not have the prefix affixed to it, you inform your assembler this by using the [bits 32] command. Also, pmode is not 32-bit by itself, there is 16-bit pmode and 32-bit pmode, and similarly, it uses these prefixes and can still run 32-bit code, however program size grows much faster due to having the prefix attached to each opcode (making the code slightly slower and take up more memory).

Ready4Dis wrote:Yes, 16-bit rmode just means the default operation is 16-bits, you can do 32-bit operations, but each instruction will have a 0x66 prefix added to it to denote that it is a 32-bit instruction while in 16-bit mode. All 3 of those instructions assume 16-bit mode, but the next instruction after the mov cr0, eax will assume 32-bit mode, so it will not have the prefix affixed to it, you inform your assembler this by using the [bits 32] command. Also, pmode is not 32-bit by itself, there is 16-bit pmode and 32-bit pmode, and similarly, it uses these prefixes and can still run 32-bit code, however program size grows much faster due to having the prefix attached to each opcode (making the code slightly slower and take up more memory).

Not completely correct (It seems to be a common misunderstanding):
Changing the PE bit in CR0 differentiates between real mode and protected mode. The move doesn't force the processor into 32-bit mode, but leaves it where it was. So, when you enable PE, you'll be in 16 bit protected mode. To enter 32-bit protected mode, you'll have to reload CS (the far jump).

I think that clears it up. I thought that the Protected Mode is a 32-bit mode, but now I now the truth

Combuster wrote:

Ready4Dis wrote:Yes, 16-bit rmode just means the default operation is 16-bits, you can do 32-bit operations, but each instruction will have a 0x66 prefix added to it to denote that it is a 32-bit instruction while in 16-bit mode. All 3 of those instructions assume 16-bit mode, but the next instruction after the mov cr0, eax will assume 32-bit mode, so it will not have the prefix affixed to it, you inform your assembler this by using the [bits 32] command. Also, pmode is not 32-bit by itself, there is 16-bit pmode and 32-bit pmode, and similarly, it uses these prefixes and can still run 32-bit code, however program size grows much faster due to having the prefix attached to each opcode (making the code slightly slower and take up more memory).

Not completely correct (It seems to be a common misunderstanding):
Changing the PE bit in CR0 differentiates between real mode and protected mode. The move doesn't force the processor into 32-bit mode, but leaves it where it was. So, when you enable PE, you'll be in 16 bit protected mode. To enter 32-bit protected mode, you'll have to reload CS (the far jump).

The point of the far jumpis surely to reload the cs register with something meaningful in protected mode. If you carried on with the PE flag set, and with a paragraph address (rather than an index into the GDT) in cs, the system would crash.

mathematician wrote:The point of the far jumpis surely to reload the cs register with something meaningful in protected mode. If you carried on with the PE flag set, and with a paragraph address (rather than an index into the GDT) in cs, the system would crash.

Oh, the magic of Unreal Mode.

As long as nothing is done with the contents of CS, its perfectly safe to leave it in place. The system only acts on the hidden parts of the CS register. As long as CS (or any segment register for that matter) isnt written to, these values remain unchanged, and your code will happily carry on. Exceptions and interrupts however are disastrous in such a state.

Hi,

INF1n1t wrote:I think that clears it up. I thought that the Protected Mode is a 32-bit mode, but now I now the truth

There's also other CPU modes...

For long-mode it's similar to protected mode, but there's 3 different code segment types:

• 16-bit protected mode compatible (16-bit default sizes, with overrides for 32-bit)
  32-bit protected mode compatible (32-bit default sizes, with overrides for 16-bit)
  64-bit (32-bit default sizes, with overrides for 16-bit and 64-bit)

For SMM, it's almost identical to "unreal mode" (real mode without segment limits).


Cheers,

Brendan

Oh, of course I want to use 32 Bit Protected Mode, so I did a far jump to an offset at 1MB memory mark and load CS with the correct selector value! I've used

As I've read in the nASM manual!!!