Virtual memory : new milestone reached !

Greetings everyone !

Though I did not find as much time and motivation to work on the OS as I would have wished (holidays are just better for code ^^), that doesn’t mean there’s no progress ! Because finally, my paging management class can fully initialize itself, mapping the kernel’s virtual memory in a page-perfect fashion. (The more I write C++ code, the more I think that constructors are the hardest part to write in a class)

See that thing in red ? Making it appear was not trivial...

All I have to do now is to code its member functions (should be rather easy, some algorithms can be stolen from my physical memory management code). Then, it’ll be time to religiously write my kernel-level memory allocator. And once I have this… A new world of opportunities is unfolding. I’ll probably start by cleaning up and reviewing memory management in depth, and then it’ll be time for work on interrupt management (leading to keyboard input and threads/processes/scheduling in the future)…

The good thing with the beginning of a big project like an OS is that you always have something interesting to do. The bad thing is that you always feel guilty when you see the amount of work left and think that you could have done more…

Oh, and by the way, I’ve got a challenge for readers, if I did not make all of them flee in disgust already : I have some issues with my debug stream and don’t know how to get rid of them. Maybe someone with C++ knowledge can help me ?

  1. My dbgout class does not accept pointers as entry types. So normally, dbgout << some_pointer should not be compiled and result in some horrible error message.
    However, since I introduced support for boolean input (using the standard “bool” type), this does not happen anymore. Instead, pointers of any type are interpreted as boolean values. WTF ???
  2. To control the way output is handled, I introduced modifiers, in a STL-like fashion. As an example, dbgout << txtcolor(TXT_LIGHTRED) changes text color to light red. Internally, this works using classes (in this case the DebugAttributeChanger class) and operator overloading.

    Problem is, using a modifier several times fails.As an example, dbgout << txtcolor(TXT_LIGHTRED) << “RED” << txtcolor(TXT_LIGHTGRAY) << “GRAY”; will result in a “REDGRAY” text output uniformally colored in red. Same goes for every single other modifier I’ve created. Does anyone have a clue about why this is happening ?

Advertisements

4 thoughts on “Virtual memory : new milestone reached !

  1. Amenel October 10, 2010 / 1:00 am

    “The more I write C++ code, the more I think that constructors are the hardest part to write in a class”. Quick take on this without further thinking: my current professional project with Java makes me believe that the trickiest (not “hardest”) part in OOP is cherrypicking what to use as parameters, even in class methods, and what to use as class members. With the experience, I’ve come to realize that the “shared or not?” question is no longer enough for good design and flexible implementation.

    Sorry I can’t be of any help as for your issues. My proficiency in C++ has plummeted due to using exclusively Java in my job(s). Since overloading in C++ tends to make some (sometimes strange to me) use of implicit conversions, a good thing to do could be to overload the << operator with an argument type "closer" to pointer than bool? Maybe flushing the stream will help in issue #2? I've never been able to use streams in C++, due to 1- me cringing at the syntax and semantics and 2- making GUI programs. The rare times I had to output things, I'd prefer the printf gang.

    OK, so now the VM can be considered done. Any next milestones chosen yet beyond the memory allocator? Or you'll just follow your heart's will?

  2. Hadrien October 10, 2010 / 9:32 am

    “The more I write C++ code, the more I think that constructors are the hardest part to write in a class”. Quick take on this without further thinking: my current professional project with Java makes me believe that the trickiest (not “hardest”) part in OOP is cherrypicking what to use as parameters, even in class methods, and what to use as class members. With the experience, I’ve come to realize that the “shared or not?” question is no longer enough for good design and flexible implementation.

    Sorry, I did not understand that. Could you please try to reword it or illustrate it with some examples ?

    Sorry I can’t be of any help as for your issues. My proficiency in C++ has plummeted due to using exclusively Java in my job(s). Since overloading in C++ tends to make some (sometimes strange to me) use of implicit conversions, a good thing to do could be to overload the << operator with an argument type "closer" to pointer than bool?

    Indeed, overloading it to void* in the header without actually implementing the corresponding function somewhat works (minor issue being that the build fails at link time and not compile time). I suppose the problem is that in C derivatives, pointers are often implicitly casted as booleans for checking their validity, using something like if(pointer).

    Maybe flushing the stream will help in issue #2?

    Well, the problem is that there’s nothing to flush. This is debug output, after all, so I didn’t bother to put a buffer in the implementation (what would be the point ? Current builds of the kernel are mono-tasking anyway).

    What’s absolutely incomprehensible is that if I write…
    dbgout << txtcolor(TXT_LIGHTRED) << "RED";
    dbgout << txtcolor(TXT_LIGHTGRAY) << "GRAY";

    …like in my current code, it just works.

    I just can’t see why this happens, to the point that I wrote a bug report for it in my own bug tracker ^^’

    I’ve never been able to use streams in C++, due to 1- me cringing at the syntax and semantics (…) The rare times I had to output things, I’d prefer the printf gang.

    Funny, myself I think that I/O streams are one the best things that C++ has introduced syntactically-speaking. No obscure formatting strings that you have to know by heart, you just put everything in cout and cout displays it for you. OOP’s “black box” programming model at its best.
    Guess such opinion divergences are why Stourstrup made C++ so complicated in his attempt to put every single programming paradigm in it.

    and 2- making GUI programs.

    Thanks for recalling me to make a post about the programming tools I plan to introduce, although you probably did not do it on purpose ;)

    OK, so now the VM can be considered done. Any next milestones chosen yet beyond the memory allocator? Or you’ll just follow your heart’s will?

    Well, as I said, my next target will be interrupt handling. Among other things, this opens the way for keyboard input (a very precious debugging resource, be it only because it allows for breakpoints on VirtualBox or real hardware) and task scheduling (for thread and process preemptive multitasking, which is after all the most central task of a micro-kernel). For a longer-term roadmap, see the project’s pretty Trac. (As you can see, I planned to do interrupts BEFORE memory allocation intially, but it appears that the two problems are deeply entangled and that I have to solve at least part of one to solve the other)

  3. Tom Novelli April 5, 2011 / 3:40 pm

    I ran into similar problems using C++ stream modifiers for colorized debugging messages. I wanted to save the previous color(s) on a stack:


    cerr << color.push(C_RED) << "Fatal Error" << color.pop() << newline;

    Trouble is, most compilers use right-to-left evaluation order, so pop() executes before push(). There is a solution but it’s not nearly as straightforward as putting push() and pop() in separate statements. C++ streams are a failure, I’m afraid. Like Amenel, I went back to using printf(). Then I went back to plain C, using the UThash macro library instead of STL maps/vectors/lists.

    I really don’t think C++ is a good choice for OS implementation, especially on your first attempt. You’ll get distracted by all kinds of language issues. Some of the newer languages are designed better than C++, but those are mostly dynamic/interpreted languages with complex runtime environments, not suitable as system languages.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s