OSDev.org

Question1
Ok , when I am in real mode can I still use 32bit instructions / registers ?
For example mov eax 52h instead of mov ax 52h or is this mode strictly 16bit code.
If so why the restriction.

If I am in real mode and turn on the cr0 A20 bit will I beable to access the same amount of memory 4GB that I can in protected mode without going into protected mode?

Question2
When in protected mode can you have more then 256 IDT entries in your IDT? Or can their only be at most 256 different isrs routines ever?

Out of the isrs routines their are special isrs routines named irq's . Correct me if I am wrong but I believe their is only 16 irq and can be only 16 at most. I am wondering what the difference between these and the regular routines are.... past the fact they are at different numbers in the table and in protected mode have to be remapped so they don't call a wrong fault routine.

Question3
To go from real mode to protected all
you have to do is setup your GDT , and IDT as well as point the gdtr , ldtr to the begining of the tables.
then switch on the A20 line
then do a far jump

My question is why the far jump what does that do for me? I get the A20 line the hardware guy's had to do that so it would be backwards compatible and switching it on makes it so it not like mod 2^20 for segment:offset...etc

Question4
How many GDT entries can you have in a GDT? This question is similar to how many IDT entries you can have in an IDT. But I am wondering if you can have more the 256 in a single GDT table?

Question 5
In real mode the IVT is fixed and located from memory address 0x0000 to 0x03ff so the first 1024 bytes in memory. Make since since 256 entries * 4bytes (32bits) = 1024 bytes
In protected mode you can set the IDTR , and GDTR to point to any location thus putting the begining of the GDT,IDT tables anywhere in memory.

If I wanted to change back from protected mode to real mode provided I didn't overlay the IVT with the GDT , or IDT tables do I just set the GDTR entries back to all 0 and IDTR to point to start of the IVT which is at 0x0000 memory address , Then set the A20 back off and that's it. Or must I do some far jump thing as well?

Question 6
I have looked up the IRQ routines I am assuming their is only 16 available but I don't see any for the NIC card or Video Card Or any other PCI card like fax ,...etc
Wondering how these hardware devices trigger an interrupt? Like what happens if the nic card is send a packet how will the x86 arch know that the device has to trigger a given interrupt if their is no fixed interrupt for it ,...etc?
For instance if a key is pressed on the keyboard I know whatever I set my IDTR I know the 33 entry IRQ 1 entry holds the address of the function that will be called when pressing a key on the keyboard or any other keyboard related issue....
In theory their should be a fixed function entry for each of the hardware devices so you can code when an interrupt has occured from a given hardware like nic ,...etc?

So I am little confused about how to code for a NIC interrupt , fax v.92 interrupt ,...etc

Thanks for clearing any of this up

Salutations,

1: Yes. The assembler generates the overrides to allow you to use the larger register set.
2: Nope, 256 is the architectural maximum.
3: You need not set up Interrupts handling before switching to Protected mode. In fact, loading a 32 bit IDT in Real Mode when the legacy 16 bit IVT is expected will cause a processor reset. Just load a GDT into the GDTR, disable interrupts, and then switch modes. Also, remember that the A20 is not part of the processor's switch to protected mode. It's just a chipset detail to allow to address wraps while the CPU is in real mode.
4: You may have a maximum of 8192 selectors in a GDT. To expand upon this, you may use multiple GDTs, or have LDTs pointed to in your GDT.

6: There are 256 interrupt vectors, and the original ISA bus, since it did not have software configurable IRQs for devices simply hardwired the IRQs, and had them changeable via jumpers. A device can configure itself to generate IRQs at a particular vector. The ISA IRQs are managed by the ISa standard Interrupt Controller, the PIC. There are other buses in modern PCs which can latch onto other IRQ vectors.

There are no fixed "IRQ" vectors. The processor "reserves" several vectors for itself as exception vectors, but devices can still logically fire IRQs on those vectors. I not sure whether I understood your question properly, though.

I couldn't answer #5 sensibly, either.

--All the best,
aeritharcanum

First, i'm going to be nice this time... but all (most) of the answers I'm about to give will involve a link to the amazing and very much useful OSDev Wiki containing one of the articles that should be read relating to the subject.... second, I suggest that you read both the AMD and Intel Architecture Developer's Manuals...
but please RTFW (read the ******* wiki) have a nice day.

Sam111 wrote:When I am in real mode can I still use 32bit instructions / registers ?

Yes, as long as you are on a 80386+ CPU (32-bit CPU)

Sam111 wrote:If I am in real mode and turn on the cr0 A20 bit will I beable to access the same amount of memory 4GB that I can in protected mode without going into protected mode?

Sortof.... see Unreal Mode AND A20 Line

Sam111 wrote:When in protected mode can you have more then 256 IDT entries in your IDT? Or can their only be at most 256 different isrs routines ever?

Sortof... you can have more than 256 but they will be ignored by the CPU.... see Interrupt Descriptor Table

Sam111 wrote:Out of the isrs routines their are special isrs routines named irq's

Yes... see Interrupts AND Programmable Interrupt Controller AND Advanced PIC

Sam111 wrote:Why the far jump what does that do for me?

The far jump forces CS (the code segment) to reload witha valid 32-bit GDT entry...

Sam111 wrote:How many GDT entries can you have in a GDT?

8192 entries is the max... See Global Descriptor Table
on a side note however... many people and most modern operating systems (linux, windows) don't use segmentation, they setup the GDT to allow for 'Flat' memory access... in fact hardware based segmentation was completely removed for long (64-bit) mode

Sam111 wrote:If I wanted to change back from protected mode to real mode provided I didn't overlay the IVT with the GDT , or IDT tables do I just set the GDTR entries back to all 0 and IDTR to point to start of the IVT which is at 0x0000 memory address , Then set the A20 back off and that's it. Or must I do some far jump thing as well?

First, real mode is just as customizable as any other mode... you can move the IDT to any address, as well as the real mode GDT, etc...
See Switching back to Real Mode

Sam111 wrote:So I am little confused about how to code for a NIC interrupt , fax v.92 interrupt ,...etc

I suggest you read Buses specifically PCI...

Create a plain text file called 'booting.asm'. The first thing we should do, is to tell the compiler, we're compiling to 16-bit instructions. Remember, at the start-up, the computer operates in Real mode (16-bit).

This quote from Bona fida os dev

So this makes me thing I have to be in protected mode to use 32bit instructions/registars?
Which you told me it was ok to use mov eax , 52h ,...etc ?

I mean I get from a complier/translator ,...etc point of view that the code will compile ,..etc
But will it run if I am in real mode (16bit mode <--they call it) and run correctly???

Basically can you use 32bit instruction and registars in real mode?
It seems to me you should beable to at least use the 32 bit registars not so sure on the total instruction set
though? curious

If their is any problems with the instruction set they could only be from not having the full address lines which can be enabled by the cr0 bit.

If using 32bit stuff in real mode is ok then if I compile my nasm program with [BITS 32] it should work fine.
Correct me if I am wrong.

Ok, this is a table taken directly from the "AMD64 Architecture Programmer's Manual - Volume 3: General-Purpose and System Instructions", it should help explain as should the text that follows.
The table shows that in Real Mode, we have a default address size of 16-bits... and we can have an effective address size of 16 or 32 bits... to use 32-bit addresses in real mode we must add an instruction prefix (0x67)...
The tables shows that in Real Mode, we have a default operand size of 16-bits... and we can have an effective operand size of 16 or 32 bits... to use 32-bit operands in real mode we must add an instruction prefix (0x66)...

To sum it up, yes the CPU will have no problems executing 32-bit code in real mode. Just write the program (I assume your using nasm) as normal with a [BITS 16] directive up top.... and were you need to use 32-bits, just use them... nasm will do the rest

an example follows

Then I guess what I am confused about is what the purpose of BITS 16 or 32 is in nasm?
Could I use BITS 32 instead. Their must be some difference?
I guess the only thing I could see is the prefixes 0x66 or 0x67 being changed if I use BITS 16 or 32?
Don't know how this will effect everything ,.....

Hi,

Sam111 wrote:Then I guess what I am confused about is what the purpose of BITS 16 or 32 is in nasm?

The "BITS 16", "BITS 32" and "BITS 64" directives tell the assembler to generate code where the default operand and address sizes are 16-bit, 32-bit and 64-bit. This is only a default, and can be overridden by an operand size override prefix or an address size override prefix.

For example, if you use "BITS 16" to tell the assembler you want 16-bit code as the default, and then use a 32-bit instruction (e.g. "mov eax,0x12345678"), then the assembler can figure out that an operand size override is required to make it 32-bit.

Sam111 wrote:Could I use BITS 32 instead. Their must be some difference?

What you use must match the mode the CPU will be in; because different instructions are decoded differently in different modes. For example, the opcode 0x01 is used for "add ax,bx" in 16-bit mode, and the exact same opcode 0x01 is used for "add eax,ebx" in 32-bit mode. If the CPU expects 16-bit code and you tell the assembler to create 32-bit code, then when you write "add eax,ebx" the CPU will think you mean "add ax,bx"; and when you write "add eax,0x12345678" the CPU will think you mean "add ax,0x5678" and also think that the extra bytes from "0x1234" are another instruction.

Sam111 wrote:Don't know how this will effect everything ,.....

You don't need to know how it effects everything - the assembler figures it out. The only thing you need to do is make sure you tell the assembler (using the "BITS 16", "BITS 32" and/or "BITS 64" directives) to generate code that matches what the CPU expects. The assembler will generate an error if you try to use an instruction that isn't possible in the current mode (but would be possible in a different mode).


Cheers,

Brendan

so when the computer first starts up (i.e is in real mode)
Is the only BITS directive to use 16?

Because I thought the instruction set is backwards compatible so a 16bit instruction is the same as the 64 bit one except they pad it with zero's...etc

I really don't see the difference in using BITS 16 , 32 , 64 other then the fact that you are allocating 2 , 4 , and 8 bytes for a given instruction respectfully.

So the only thing I can see is that if the computer is in real mode reading each instruction as a 2byte thing and you compile as BITS 32 which makes each instruction 4bytes long then you will be reading a half of an instruction ,...etc which is probably going to crash and burn very fast.

Correct me if I am wrong.

I am still thing I am missing something since a 32bit machine should execute always 4byte instructions and to make 16bit instructions execute correctly they pad it to make it a 4bytes instruction.

Still confused sorry for being stupid with this one

What you use must match the mode the CPU will be in; because different instructions are decoded differently in different modes

I thought the 16 bit instruction set in 32 bit mode is backwards compatible they just pad it with 2 more bytes in 32 bit mode instructions.
I guess I don't understand how the cpu runs 16bit code differently then 32 bit code I would think on a 32bit processor running 16bit code is just running 32bit code but with 2 bytes just paded that aren't used.
Because I 32 bit machine uses 4 byte instructions on each instruction read....

????
Guess I don't understand the difference between 16bit instructions and the same instructions in 32 bit they should be the same

No, the bits directive specifies the current default operand and address size. It's not the instruction length. Instructions have variable length.

Instructions are never padded. If a 66h byte precedes an instruction, the operand size changes from 16 bit to 32 bit or from 32 bit to 16 bit. Similarly, the 67h byte changes the address size. For example, if the default size is 16 bits, 89 C8 means mov ax,cx and 66 89 C8 means mov eax,ecx. Similarly, B8 34 12 means mov ax,1234h while 66 B8 34 12 00 00 means mov eax,1234h. In 32 bit mode, 66 B8 34 12 means mov ax,1234h and B8 34 12 00 00 means mov eax,1234h.

In real mode, or when the code segment has a cleared D bit, the default size is 16 bit, and when the D bit is set, the default size is 32 bit, so the corresponding bits directive should be used. For a 64 bit code segment, the default size is still 32 bit, but the meaning of opcodes 40-4fh has changed and some instructions are invalid.

Hi Sam111,
Have you read the Intel manual? Recent manuals are hundreds of pages, but you could start with the "Intel 80386 Programmer's Reference Manual" from 1986, which is not that thick. It can be found on various places on the web. For learning x86 assembly language, I suggest "Art of Assembly Language Programming" by Randall Hyde.

Roel