OSDev.org

How did you know that? why the upper 13bits in the cs register are an index into a code segment descriptor? Is all x86 computers made like this? And by code segment descriptor you mean apart of an entry in the GDT table (limit and base)

Yes, that's how it works on all x86 processors when in protected mode. A code segment descriptor is an entry in the GDT whose bits 43 and 44 are set to 1. Bit 0 and 1 of a segment selector determine the protection level to use, which must be at least as high as the DPL of the segment descriptor (bits 45 and 46). Bit 2 of a selector, when set to 1, indicates that the segment descriptor is to be taken from the current LDT instead of the GDT. So, a selector of 8 would refer to the descriptor at GDT offset 8 with a protection level of 0, and a selector of 1fh would refer to the descriptor at LDT offset 18h with a protection level of 3.

Could I call a 32 bit program if I manual put a 66 or 67 prefix on it.
Instead of going into protected mode?

The 66h and 67h prefixes only affect the following instruction. A call or jmp instruction prefixed with 66h indicates a 32-bit destination address, but the called code still runs in 16 bit mode.

If I didn't want to go into protected mode can I just go into unreal mode without going first into protected mode?
What would happen if I set the cr0 bit to protected mode but I never setup the GDT stuff or did a far jump just curious?
Where is the default gdtr , ldtr ,...etc pointing before setting them up curious?
I am thinking the ldtr is pointing to the IVT at 0x00000000 ... though I am not 100% sure.

No, to go into the so-called unreal mode, you first have to go to protected mode, because that's how you load the segment registers with different limits and default operand sizes. At startup, the LDTR is set to 0, but still marked as present with a base address of 0 and limit of 0ffffh. The GDTR also has a base of 0h and a limit of 0ffffh. However, you should not rely on the initial value of LDTR and GDTR, since the BIOS uses them during booting. If you don't change GDTR, it will likely point to a GDT in ROM which often begins with 32-bit code and data segment descriptors with base 0 and limit 0ffffffffh, but this can change between BIOSes. If you don't do a far jump and do not change the segment registers, nothing will happen and you will still run in 16 bit mode with the same segments as before.

If you run in 32 bit unreal mode, interrupts must be disabled or handled by your own code, and EIP must be below 10000h at all times while interrupts are enabled.

Being on a 32bit arch x86 machine is their any other modes other then real mode , unreal mode , and protected mode? ( I know when we go to 64bits they have one more called long mode)
Another words is their any different mode or corosponding bits for modes that I haven't commented on?

Unreal mode isn't a mode, it's just real mode with segment descriptors having been loaded in protected mode. Long mode is a form of protected mode. When in protected mode (and not in long mode), you can go to virtual 8086 mode by executing an IRET instruction with bit 17 of the EFlags on the stack set. In this mode, segments work like in real mode, but interrupts and exceptions cause the processor to exit virtual 8086 mode unless redirected to the virtual 8086 mode program using the interrupt redirection bitmap in the TSS. Segments are fixed with limits of 0ffffh, protection level of 3, and operand size of 16 bits, and the IVT is fixed at 0.

Is their any other difference in unreal mode from real mode apart from the fact you can access all 4GB of memory in unreal as opposed to real?
Can you still use the IVT of real mode in unreal mode ,...etc ?

No, you can use the IVT just like before. However, if the default operand size has been set to 32 bits, the interrupt handlers must also consist of 32 bit code.

The higher 13 bits are used because the lower 3 bits encode addresses from 0 to 7, and that's because each GDT selector is 8 bytes long, and by using the higher 13 bits as index the location of the GDT selector is aligned to 8 bytes (in steps of .

Let me get this straight
cs is 16bits the left most 13bits corosponds to what GDT entry you are selecting?
Does it corrospond not to the data in the GDT but the actual entry number in the GDT.
For example if cs has the highest 13 bits as below
So 0000000000001 => second entry , 0000000000010 => third entry , 0000000000011 => fourth entry in the GDT ,...etc is that what it is.


For instance if I had 8000h in the cs registar in real mode what would that be in protected mode?
Would it corospond to 4096 entry in the GDT is that what the 13 bit's corosponds to the index into the GDT.
If I am correct in this statement I am still curious what the 3 other bits are for and corospond to???
Both for real and protected mode.

what is this lower 3 bit encodeing corrospond to 0 - 7 what are these for?

Sorry if I am being repeative I just want to understand all the details it makes it so much easier to understand the code in the end.....

Is this 13 bit thing the same for all x86 machines or is it a more universial to other arch as well ?

Also I have been reading about the A20 line when do you need to use this and why. It has something about the address wrap around mod 2^20 address thing ... so if you are in protected mode can you still access 4GB of memory or do you have to muck with the A20 line first.

Sam111 wrote:

The higher 13 bits are used because the lower 3 bits encode addresses from 0 to 7, and that's because each GDT selector is 8 bytes long, and by using the higher 13 bits as index the location of the GDT selector is aligned to 8 bytes (in steps of .

Let me get this straight
cs is 16bits the left most 13bits corosponds to what GDT entry you are selecting?
Does it corrospond not to the data in the GDT but the actual entry number in the GDT.
For example if cs has the highest 13 bits as below
So 0000000000001 => second entry , 0000000000010 => third entry , 0000000000011 => fourth entry in the GDT ,...etc is that what it is.

Hence the 0x08, 0x10, 0x18, etc. whenever you see someone setting up the GDT.

Sam111 wrote:For instance if I had 8000h in the cs registar in real mode what would that be in protected mode?

The way protected mode works is that you can use the segments to define what memory regions should be accessable. Usually that's configured to 4GB .text and 4GB .data so that there is no limit. Segmentation itself isn't needed in protected mode as you can directly access all 4GB RAM after setting up the GDT properly. The segments in real mode are used to describe what segment should be accessed (e.g. 0x8000:0xB000 should access 0xB000 in segment 0x8000, in that case the physical address would be 0x8B000).

Sam111 wrote:Is this 13 bit thing the same for all x86 machines or is it a more universial to other arch as well ?

Segmentation doesn't exist on ARM, PPC, SPARC and MIPS, so the answer would generally be no. Although, there might be some other ancient processors supporting it.

Sam111 wrote:Also I have been reading about the A20 line when do you need to use this and why. It has something about the address wrap around mod 2^20 address thing ... so if you are in protected mode can you still access 4GB of memory or do you have to muck with the A20 line first.

The A20 line was a compatibility measurement. In real mode you were able to access more than 1MB, but you'd just be accessing the RAM starting from 0x00000000. This is what we call wrapping. By enabling the A20 the memory won't wrap and you'll be able to use the 21st address line, thus you'd be able to access 1MB+ properly.


Regards,
Stephan J.R. van Schaik.

Ok , I am just confused about one more thing with memory.
segment:offset

0000:0000 - FFFF:FFFF interms of physical address this is memory 0 - 1114095 approx little more then 1MB
i.e
65535 * 16 + 65535 = 1114095 to figure out the physical from the segment:offset representation.

So standard segment:offset representation can only access the first 1MB of memory approximatly.
So what is this A20 line doing 2^20 = 1048576 , 2^19 = 524288 even with this 2^20 it still doesn't get to the 1114095 address???

The most segments you can have in protected mode is 8192 segments corosponding to the max numbers of entries.
Correct me if I am wrong? ( counting the null descripter as well)
Also in protected mode can you have segments that overlap or are shared other then the standard 3 entries?

If you only allocate the 3 standard entrys in the GDT and give then all 4GB full memory how is that different from real mode?
Other then the fact that you are working with 32bit code ,registers , and more memory. Their is still only one code segment that all the programs are in unless you provide more segment descriptors.
So another words protected mode can be used as a 32bit real mode version if you don't provide any additional restrictions on segments ,...etc

Because their is only 16bits for the cs registar to use this makes the max that the cs registar can hold 0xFFFF = 65535 different segments
So it seems that real mode can have more segments then protected mode 8192 correct me if I am wrong
65535 > 8192

Thanks for all your help I think I got it now
Just to make sure gdtr is 48bits => 2bytes for the size of GDT table (limit) and 4bytes for the base address (what location the GDT starts at in physical memory)
The GDT can have at max 8192 entries which are 64bits per entry. But the size can be FFFFh = 65535 (2bytes)


So the size of the GDT table can be greater then the max entries it can contain ?


If gdtr contains FF FF 00 00 00 00 then the GDT table starts off at physical address 0x0 and the size of the
GDT table is 65535 but the max number of table entries would be 2^13 = 8192 (for getting for the moment +- 1 or so stuff )

Sam111 wrote:segment:offset

0000:0000 - FFFF:FFFF interms of physical address this is memory 0 - 1114095 approx little more then 1MB
i.e
65535 * 16 + 65535 = 1114095 to figure out the physical from the segment:offset representation.

So standard segment:offset representation can only access the first 1MB of memory approximatly.
So what is this A20 line doing 2^20 = 1048576 , 2^19 = 524288 even with this 2^20 it still doesn't get to the 1114095 address???

Accessing the memory beyond the first MiB will cause the address to wrap around and you will end up addressing the bottom of the memory unless you enable the A20 gate (which when turned off masks the 21st addressing pin), in which case you have access to an extra 64 KiB of memory called the HMA (High Memory Area) - which you should be careful about because some BIOSes like to do shadowing there. You can leave it disabled in protected mode if you like but you won't be able to access every odd MiB of memory.

The most segments you can have in protected mode is 8192 segments corosponding to the max numbers of entries.
Correct me if I am wrong? ( counting the null descripter as well)
Also in protected mode can you have segments that overlap or are shared other then the standard 3 entries?

You can do whatever you like with your entries but not using the flat memory model will cause the hardware to do extra checks with every memory access and will make it hard for you to build applications for your OS because compilers for such applications are more difficult to write. (Note that segmentation works on top of virtual memory.)

If you only allocate the 3 standard entrys in the GDT and give then all 4GB full memory how is that different from real mode?
Other then the fact that you are working with 32bit code ,registers , and more memory. Their is still only one code segment that all the programs are in unless you provide more segment descriptors.
So another words protected mode can be used as a 32bit real mode version if you don't provide any additional restrictions on segments ,...etc

Are you asking the difference between using a flat memory model of 4 GiB and using an overlapped segmented memory model that can access a total of 1 MiB + 640 KiB? No, it's the same. By the way, you should also look into the undocumented unreal mode, which gives you access to the full 4 GiB address space by extending real mode segments using segment descriptor cache magic.

Gotcha

what about this stuff

Because their is only 16bits for the cs registar to use this makes the max that the cs registar can hold 0xFFFF = 65535 different segments
So it seems that real mode can have more segments then protected mode 8192 correct me if I am wrong
65535 > 8192

Thanks for all your help I think I got it now
Just to make sure gdtr is 48bits => 2bytes for the size of GDT table (limit) and 4bytes for the base address (what location the GDT starts at in physical memory)
The GDT can have at max 8192 entries which are 64bits per entry. But the size can be FFFFh = 65535 (2bytes)


So the size of the GDT table can be greater then the max entries it can contain ?


If gdtr contains FF FF 00 00 00 00 then the GDT table starts off at physical address 0x0 and the size of the
GDT table is 65535 but the max number of table entries would be 2^13 = 8192 (for getting for the moment +- 1 or so stuff )

And another words if I don't enable the A20 line then I still cann't access alll of the 4GB memory.
Yes/No? And if Yes when should I enable it after protected mode or before or ( it doesn't matter as long as I have interruots shut off with cls )

Those questions weren't worth answering. They looked like random questions from someone who his research superficially. I thought A20 was worth menioning because it's not really in the Intel manuals (well, sort of) so it's harder to research And as I was saying, segmentation works on top of virtual memory so that's not a physical address.

The GDT limit contains the GDT size in bytes minus 1. Since each entry contains 8 bytes, the maximum number of entries is 8192. It doesn't matter when you enable the A20 gate, since it is independent of processor mode, but it should be done before accessing any memory whose address bit 20 equals 1.

The GDT base, as well as all segment bases and the IDT base, are virtual addresses. When paging is disabled, physical addresses are equal to virtual addresses.

Gotcha

The GDT base, as well as all segment bases and the IDT base, are virtual addresses. When paging is disabled, physical addresses are equal to virtual addresses.

I always thought when I put the 32 bit base value in the 48bit gdtr it is the physicall address of the location where the GDT begins in memory.... how is this virtual ? Maybe paging is the key I haven't done anything with this or looked into this yet though. If pageing was enabled correct me if I am wrong I would still put the same base address as I loaded it when I had paging off.

Also the IDTR is 48 bits like the GDTR with 2 bytes for the size correct me if I am wrong but the max entries a IDT can have is 256 (equivalent to the real mode IVT) but the table can be the max size 2 bytes can hold
which is FF FF = 65535 ???

Thanks for all your help in understanding this stuff

I haven't done anything with this or looked into this yet though

And that attitude IMNSHO deserves a ban. DO YOUR HOMEWORK BEFORE ASKING for crying out loud. You are wasting our time.

The OP obviously doesn't intend on listening to advice given or doing his own research. We're here to help, not to spoon feed. Go read the intel manuals, try things out on your own (and debug it) then perhaps come back when you're a bit more willing to follow advice, rules, and work with the community.