gdt, ldt, idt, etc...

Zacariaz · Post by **Zacariaz** » Tue May 22, 2007 5:19 pm

Does anyone know a good and understandable resource on the net where it is all discibed:
What they are, why/if you need them, how you should do the code, etc.?

Thanks in advance.

Kevin McGuire · Post by **Kevin McGuire** » Wed May 23, 2007 1:01 am

I do not think I have ever seen that described anywhere on the internet. Do you think there really exists something called a GDT, LDT, and IDT?

This page is all Google found, but it does not look like what you want?
http://www.google.com/search?hl=en&q=GD ... tnG=Search

That first page in the list is got to be something completely useless.

The sixth or seventh is some page about some weird protection mechanisms.. I mean what in the world is there no information on these things or what? I give up searching..

Combuster · Post by **Combuster** » Wed May 23, 2007 2:14 am

Try the following:
www.intel.com
www.osdev.org/wiki
www.kernel.org
www.yourownimagination.com

Zacariaz · Post by **Zacariaz** » Wed May 23, 2007 7:28 am

Thank you for the sarcasm.
What i ment was of course not that i havent found anything but that what i have found is missing alot or is hard to understand.

jnc100 · Post by **jnc100** » Wed May 23, 2007 7:41 am

Very simply:

GDT, LDT and IDT are tables, stored in memory, which are directly used by the processor in protected mode.

The global descriptor table contains entries describing memory. In particular, they define what each segment of memory refers to. You make a reference into the GDT every time you load a segment selector into one of the segment registers (DS, ES, CS, SS, FS or GS). The segment descriptor (GDT entry) contains the base address of the segment, its size (limit), access rights to the segment and what the segment is used for (e.g. code, data, tss). Then, any attempt to use the segment register to access a particular area of memory (e.g. es:[edi]) will (assuming the protection checks are satisfied) actually refer to the memory location at edi + the base specified in the segment descriptor that es points to.

Most modern (32-bit) operating systems define 6 gdt entries:

NULL (has to be the first entry)
then both a code and data segment for privilege levels 0 and 3
a tss

The code and data segments normally have their base address at 0x0 and their limit set to access the entire 4GB linear address space.

The local descriptor table (LDT) is like the GDT, only that it can change for each process. It is not necessary to use (I don't).

The interrupt descriptor table (IDT) contains the address of code to access when a particular interrupt occurs within the processor (an exception, software interrupt - INT 0x80 for example, or an external interrupt - normally an IRQ line).

The first volume of the Intel Manuals contains this information and it is pretty much a requirement to read it cover to cover (with the possible exception of the MMX and SSE stuff, which you can leave till later) in order to start an OS. AMD has a similar manual.

Regards,
John.

xyjamepa · Post by **xyjamepa** » Wed May 23, 2007 8:06 am

Hi...
try thishttp://www.osdever.net/bkerndev/index.php

Zacariaz · Post by **Zacariaz** » Wed May 23, 2007 9:36 am

jnc100 wrote:Very simply:

GDT, LDT and IDT are tables, stored in memory, which are directly used by the processor in protected mode.

The global descriptor table contains entries describing memory. In particular, they define what each segment of memory refers to. You make a reference into the GDT every time you load a segment selector into one of the segment registers (DS, ES, CS, SS, FS or GS). The segment descriptor (GDT entry) contains the base address of the segment, its size (limit), access rights to the segment and what the segment is used for (e.g. code, data, tss). Then, any attempt to use the segment register to access a particular area of memory (e.g. es:[edi]) will (assuming the protection checks are satisfied) actually refer to the memory location at edi + the base specified in the segment descriptor that es points to.

Most modern (32-bit) operating systems define 6 gdt entries:

NULL (has to be the first entry)
then both a code and data segment for privilege levels 0 and 3
a tss

The code and data segments normally have their base address at 0x0 and their limit set to access the entire 4GB linear address space.

The local descriptor table (LDT) is like the GDT, only that it can change for each process. It is not necessary to use (I don't).

The interrupt descriptor table (IDT) contains the address of code to access when a particular interrupt occurs within the processor (an exception, software interrupt - INT 0x80 for example, or an external interrupt - normally an IRQ line).

The first volume of the Intel Manuals contains this information and it is pretty much a requirement to read it cover to cover (with the possible exception of the MMX and SSE stuff, which you can leave till later) in order to start an OS. AMD has a similar manual.

Regards,
John.

Well that made sence (most of it anyway, im not excactly einstein)
Thanks

Zacariaz · Post by **Zacariaz** » Wed May 23, 2007 10:05 am

abuashraf wrote:Hi...
try thishttp://www.osdever.net/bkerndev/index.php

This link is actually really great, but it uses so much C, and that is a problem. I know, bla bla bla, all of it in asm, bla bla bla, have to use C, bla bla bla.
But for now i want ot know how things work at asm level.

When every thing is said, i know how to use a statement like:
short a = 37;
But i dont really know what it does, and that is the real reason i love asm, because it lets you get down to a level where you actually know (most of the time) what is going on.

So C, C++, Pascal, or whatever, please, i have no use for them. Allso i dont much like weird macros.

Anyway, i did learn something, so thanks for the link.

Solar · Post by **Solar** » Wed May 23, 2007 11:18 am

Zacariaz wrote:
abuashraf wrote:Hi...

But i dont really know what it does, and that is the real reason i love asm, because it lets you get down to a level where you actually know (most of the time) what is going on.

This is getting really ridiculous, you know?

I'll put it blunt:

If you can't read technical manuals, and C is over your head because "you don't know what it does", don't do OS development. You're not up to it, period.

Zacariaz · Post by **Zacariaz** » Wed May 23, 2007 11:44 am

ok, this one is closed i guess, maybe i just dont speak english at all cause anytime i say something people misunderstand me.

But let me finish it of:

1. i can read tecnical manual, but really, have you tried reading intels manuals? They are writen in a language that may look like english but aint.
In order to read AND understand them you need a whole lot og Acknowledge, the kind of knowledge that you often only aquire by reading those very manuals, and excuse me, but that IS a problem.
Learning something from something you dont understand in order to understand something...

2. Ill try once more explaining myself.
I have used all those high level programming languages, and they are fine as long as you want to wrile a "hello world" program or maybe something a little more complicated, but when writing something like: std::cout << "Goodbye Cruel World!"; it may do what you expect it to do, but it says nothing about how it does it, and that may be enough for most people, but not for me. Thats why i desided to start from scratch using only assembly, because there i can see the steps and diside everything my self.

3. Anyway, this might be a wrong (probably is), but it is the only way i know of to get/learn what i want, and if anyone knows of other ways, i am listening, and listening good, cause this isnt a very rewarding aproach as learning is very slow, and good material is very hard to obtain enless you are gona spend 1000$+ on books, which i cant affort.

4. At last i will encourage anyone taking the time to read this, not to reply enless they have something usefull to say.

Thanks once again.

Combuster · Post by **Combuster** » Wed May 23, 2007 1:13 pm

Zacariaz wrote:ok, this one is closed i guess, maybe i just dont speak english at all cause anytime i say something people misunderstand me.

But let me finish it of:

1. i can read tecnical manual, but really, have you tried reading intels manuals? They are writen in a language that may look like english but aint.

Compared to some documents, the intel manuals are very understandable. Try the OpenGL extension registry if you want to get really obfuscated documentation

In order to read AND understand them you need a whole lot og Acknowledge, the kind of knowledge that you often only aquire by reading those very manuals, and excuse me, but that IS a problem.
Learning something from something you dont understand in order to understand something...

Everytime you read through it entirely, you'll figure a bit more, which means that once after reading it often enough you'll understand it completely.
Apart from that, the big difference between documentation and a tutorial is that documentation tells you what things do, while a tutorial tells you how to achieve something. If you lack the skills to make a given behaviour work for you, you wouldn't get far anywhere in the software development business. Let alone OS Development. I suggest you work on it.

2. Ill try once more explaining myself.
I have used all those high level programming languages, and they are fine as long as you want to wrile a "hello world" program or maybe something a little more complicated, but when writing something like: std::cout << "Goodbye Cruel World!"; it may do what you expect it to do, but it says nothing about how it does it, and that may be enough for most people, but not for me. Thats why i desided to start from scratch using only assembly, because there i can see the steps and diside everything my self.

You forgot why abstractions exist. Abstractions are meant to hide the implementation details from what something is supposed to do. Even assembly is an abstraction over opcodes, which is an abstraction over the functions of a large amount of logical gates. Which makes it strange why assembly does manage to be good enough. If you gave me a piece of C code I could easily work out what that would become in assembly when you compile it. Why can't you?

Try taking on something like Java to see what high-level languages can do for a person. Most people use that sort BECAUSE they want to get things done and not bother over how it is done.

3. Anyway, this might be a wrong (probably is), but it is the only way i know of to get/learn what i want, and if anyone knows of other ways, i am listening, and listening good, cause this isnt a very rewarding aproach as learning is very slow, and good material is very hard to obtain enless you are gona spend 1000$+ on books, which i cant affort.

It took me some 12 years to get where I am now, and I didn't use more than 6 books for that. I still got most of my information from the web, so given the time it can be done. Get used to not getting anywhere for prolonged periods of time.

Zacariaz · Post by **Zacariaz** » Wed May 23, 2007 1:41 pm

I dont have 12 years of experience, an i must admit that i am not a master of C

but if we can agree that C is a high level language, we can probably allso agree that if i write something in C i either have to be very experienced and/or know a great deal about the C compiler in order to figure out what really happens.
Other wise youll have to compile you program, disassemble it and so on. Figuring out the software interups and all that stuff. Im not up to that challence.
(im probably more or less wrong but i think ull understand)

Anyway, ill take your advice, an keep reading those manual over and over again till i puke

subbeh · Post by **subbeh** » Wed May 23, 2007 2:20 pm

http://www.intel.com/design/intarch/papers/exc_ia.htm

it's a short paper about protected mode. i want to say it was alright to read. was a while ago and i only skimmed the information that i needed. but i'd say intel docs or the various websites out there. tons of info on the web.

mathematician · Post by **mathematician** » Thu May 24, 2007 8:59 am

Zacariaz wrote: I have used all those high level programming languages, and they are fine as long as you want to wrile a "hello world" program or maybe something a little more complicated, but when writing something like: std::cout << "Goodbye Cruel World!"; it may do what you expect it to do, but it says nothing about how it does it, and that may be enough for most people, but not for me. Thats why i desided to start from scratch using only assembly, because there i can see the steps and diside everything my self.

You would have trouble using std::cout << "Goodbye Cruel World!" if you were writing an operating system unless you wrote at least a device driver, and probably some kernel functions, first. Which should leave you understanding how things work. Anyway C, as opposed to C++, is as close to assembly language as it gets without actually being assembly language; especially if you don't have the library functions on call. Which you don't unless you write them yourself (having first written the the OS code which supports them).