Lifelong learning

It’s been a while since I wrote something here and there’s a reason for that. I took some online courses, because … well first of all I love to learn new things and second it was about software/hardware interfacing – a.k.a. the base principles in developing your OS.

I took this course from University of Washington on coursera.org. I must say I had a little different expectations derived from the course title, but it ended up being challenging and quite useful, to say the least.

The expetations.

From the title and description I somehow thought this course would dwell deep into I/O interfaces and so on, but it ended up being just a course about CPU-memory architecture. Which wasn’t bad, I’d say wasn’t bad at all. There were a lot of things I wasn’t aware of.

The challenge.

I had set up my own threshold, that I have to finish all the assignments with the maximum grade possible (that is – the maximum grade + extra points). And I did it! Pat on my own shoulder. 🙂

The things I learned.

OK, this calls for a list:

1. GNU Assembly syntax – I had my dislikes against it, and I still do, but instead of ignoring it and trying to look up for a readable alternative I ended up understanding it. That still does not change my dislike against it;
2. GNU debugger – One hell of a swiss army knife. I’ve used a lot of different debuggers, for different purposes, but I hadn’t had a decent debugger for software written in C/Asm (well except for Visual C++ while writing desktop applications);
3. Some neat tricks with bitwise operators and strengthened my understanding in base2 numbers (especially twos-complement). For example 1 is represented as 0001 (4bits), but -1 is represented as 1111. To go from 1 to -1 you can do 0-1 or you can do (~1)+1:
   • ~1 (apply bitwise NOT): ~0001 = 1110;
   • +1 (add one): 1110 + 1 = 1111;
4. Taking advantage of CPU caches;
5. What is the Heap, the heap memory allocation and how it relates to virtual and physical memory. The kernel heap allocator is still one single thing that’s missing in my OS (I only have page identity mapper);
6. Strengthened my understanding in x86 and x86_64 calling conventions. Also now I understand how a great deal it is to use x86 64-bit OS instead of 32-bit one:
   1. Passing function arguments using CPU registers is way more faster than pushing them on the stack (RAM is slow!);
   2. Passing and reading arguments to and from the stack is dangerous – lot of classic exploits have used this to take over control of the process;
7. And those little things, that got cleared up in my mind – for example, multidimensional array layout in memory – it’s ordered in rows if you think of an array as this: array[columns][rows]. The elements of the row are put one after another in memory.

In the meantime – the OS

I’m also reading through AHCI specifications and trying to implement my AHCI driver, so that I can start reading something from the disk while in Long Mode (I don’t want to do any jumping around between Long Mode, Protected Mode and (Un)Real Mode).

I still can’t make my mind up about ACPI – should I try to incorporate ACPICA or should I write my own AML parser, or should I discard ACPI completely and just live with what the system can offer me through PCI enumeration, CPU MSRs and CPUID. It looks like I can get everything set up without ACPI, well maybe except for power management.