GDT in C++

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
CyberPsyko

GDT in C++

Post by CyberPsyko »

Hi all! I'm relatively new here. I have a question that I can't seem to find the answer for. I have been studying the various tutorials and howto's online for C++ kernel development. I want to handle GDT in C++ and not assembly (primarily because I stink at assembly... Ok, I'm not too great at C++ either, haha). Anyway, the tutorial code is:


[EXTERN _gp]
_gdt_flush:
lgdt [_gp]
mov ax, 0x10
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
jmp 0x08:flush2
flush2:
ret


How can I do this in a header file in C++? I was thinking sonething like:

asm volatile ("lgdt %d" : : "d" (gd));


This doesn't seem to be right. Can anyone help me with this? Thanks!!!
viral

Re:GDT in C++

Post by viral »

Hello..
If you have gone through basics of GDT, than I suggest you to try it out yourself. Some code can also help you.. I'll just put the steps that you can follow..

As you want to do this in C++, u'll 1st make a class say GDT which will contain all functions like:

Code: Select all

   void initGDT();
   unsigned int addDescriptor(unsigned long base, unsigned long limit, unsigned int opt);
   unsigned int removeDescriptor(unsigned int selector);
You have to maintain an array of descriptors with entries like:

Code: Select all

struct X86_DESC
{
   unsigned short   LimitLow;                // limit 0..15
   unsigned short   BaseLow;      // base  0..15
   unsigned char   BaseMed;   // base  16..23
   unsigned char   Access;      // access byte
   unsigned long   LimitHigh:4;   // limit 16..19
   unsigned long   Granularity:4;   // granularity
   unsigned char   BaseHigh;   // base 24..31
} __attribute__ ((packed));
During initialization, you have to fill this array with entries for code & data/stack segment descriptors. Then you can load the address of this table by:

Code: Select all

asm volatile ("lgdt %0" : "=m" (GdtDesc));
CyberPsyko

Re:GDT in C++

Post by CyberPsyko »

Thanks! I had almost the same code, but my syntax was off. Your suggestion really helped out. It is compiling just fine now. Now I'm on to writing my IDT... Thanks again!!
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re:GDT in C++

Post by Solar »

CyberPsyko wrote: I want to handle GDT in C++ and not assembly (primarily because I stink at assembly... Ok, I'm not too great at C++ either, haha).
Somehow this statement makes me dig in my heels and prepare for the worst... :D

Honestly. Before you think about doing OS development in anything else but Assembler, you should know at least one of the languages involved really well.

(I know some people disagree with me on this and think OS dev'ing is a great way to learn a programming language, but honestly, C++ is hard enough to get right in userspace, let alone in kernel space for a beginner...)

The reason why I make the "anything else but Assembler" limitation is that userspace assembler differs from kernel space Assembler only marginally, whereas kernel space C++ is a pretty ugly beast... (C is much more like Assembler in this regard, once you understood you don't have a library available.)
Every good solution is obvious once you've found it.
CyberPsyko

Re:GDT in C++

Post by CyberPsyko »

The bit about not being very good at C++ was more or less a joke. I just don't have much Assembler experience, thus I don't have the inline Assembler knowledgebase.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:GDT in C++

Post by Candy »

CyberPsyko wrote: The bit about not being very good at C++ was more or less a joke.
Just for hint: there are very very very few people that really know and realize how good or bad they are at c++. It's an incredibly complex language that you should take ample time to learn. There are professional users of C++ that haven't seen some parts of the language ever, who have used solely c++ at their own discretion for over a decade.

Also, don't underestimate OS development. It's a whole lot more complex than you might at first conceive, whilst you might now think it's one of the hardest things there is.
Ryu

Re:GDT in C++

Post by Ryu »

I'll have to agree C++ is a very complex language. My personal opinion is that assembly is far far easier, much less rules and restrictions which I find makes it easier, however assembly can also take several years to write code more efficency then todays compilers, this goes for both speed and binary size. Despite though, I feel every C/C++ programmer should learn the basic assembly simply to debug. As for modifying segments and special registers like GDT directly, you can't avoid assembly, even if that is inline assembly (which isn't not much differnts or no differnts at all with assembly), you can't count inline assembly as part of C++ language.
CyberPsyko

Re:GDT in C++

Post by CyberPsyko »

Agreed. As I am a professional programmer, you (as stated above) can always learn something new. I have never programmed an OS before. The point of me doing this is fun. I'm not out to change the world. I'm out to learn more about programming, and so far, this has been fun.

About Assembler, it has always intimedated me. I understand the language structure, but that is a very small part of actually programming in it. I'm slowly getting it though.... slowly. :)
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:GDT in C++

Post by Pype.Clicker »

CyberPsyko wrote: About Assembler, it has always intimedated me. I understand the language structure, but that is a very small part of actually programming in it. I'm slowly getting it though.... slowly. :)
well, i don't know too much how Dex would have agreed with that (anyone else doing hard-core assembly around?) and my own ASM is getting rusty, but imho, your pencil and paper (squared, preferably) in order to draw structurograms and whatever can help you to break the problem into smaller pieces that you can chunk at once. Unlike in C/C++, the language will not help you to see the "main lines" of what you're doing, esp. when you have to mess with the stack due to the lack of registers.

Understanding a compiler's dump for debugging is piece of cake: the compiler always uses the same idioms for the same purpose. Plus, if you're lost, the hll code tells you what is supposed to happen.

Now, making sense of hand-written assembly tuned with care by skilled programmers (i remember of my attemps to do demoscene compos and chewing phong-shading code in ASM, here) is like reading Shakespeare in its original version: you don't start by this, and if you do, you'll most likely miss all of the subtlety.
ineo

Re:GDT in C++

Post by ineo »

I agree it is difficult to use C++ for OS Development as the compiler adds a lot of things you might not expect ;)
However disabling some facilities of the C++ will ease your work, and most tutorials warn you about that.

If you don't use exceptions and virtual functions, everything works easily. Most C tutorial could be used for C++ as well (translating it into object oriented code).

Adding support for exceptions and/or virtual functions is a lot of work and depends on your compiler ABI... I tried because I wanted to learn, but it doesn't seem too useful to me for a kernel. Yet I have spend more time on understanding how C++ works than on kernel coding. I was happy to do this, but now I realize it's been a year I have not done anything new in my kernel...
Bob the Avenger

Re:GDT in C++

Post by Bob the Avenger »

I'd say the art to really good asm, is good commenting, especially when using interrupts, dont rely on your ability to remember things.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:GDT in C++

Post by Pype.Clicker »

oh, and talking about assembly, if anyone here hasn't had a look at D.E. Knuth reviewed MMIX processor already ...
Post Reply