RM and PM, 16 and 32

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
INF1n1t
Member
Member
Posts: 60
Joined: Fri Dec 22, 2006 5:32 pm
Location: Somewhere Down...

RM and PM, 16 and 32

Post by INF1n1t »

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!
I think, I have problems with Bochs. The biggest one: Bochs hates me!
m
Member
Member
Posts: 67
Joined: Sat Nov 25, 2006 6:33 am
Location: PRC

Post by m »

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.
User avatar
mathematician
Member
Member
Posts: 437
Joined: Fri Dec 15, 2006 5:26 pm
Location: Church Stretton Uk

Re: RM and PM, 16 and 32

Post by mathematician »

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.)
Ready4Dis
Member
Member
Posts: 571
Joined: Sat Nov 18, 2006 9:11 am

Re: RM and PM, 16 and 32

Post by Ready4Dis »

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).
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: RM and PM, 16 and 32

Post by Combuster »

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).
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
INF1n1t
Member
Member
Posts: 60
Joined: Fri Dec 22, 2006 5:32 pm
Location: Somewhere Down...

Post by INF1n1t »

I think that clears it up. I thought that the Protected Mode is a 32-bit mode, but now I now the truth ;)
I think, I have problems with Bochs. The biggest one: Bochs hates me!
User avatar
mathematician
Member
Member
Posts: 437
Joined: Fri Dec 15, 2006 5:26 pm
Location: Church Stretton Uk

Re: RM and PM, 16 and 32

Post by mathematician »

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.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: RM and PM, 16 and 32

Post by Combuster »

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.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
INF1n1t
Member
Member
Posts: 60
Joined: Fri Dec 22, 2006 5:32 pm
Location: Somewhere Down...

Post by INF1n1t »

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

Code: Select all

 jmp dword 0x8:00100000

As I've read in the nASM manual!!!
I think, I have problems with Bochs. The biggest one: Bochs hates me!
Post Reply