Scheduler + irq handling

The extremely basic scheduler + irq handling (not so basic, in fact very clean in high-level sources, and somewhat complicated in the assembler) features added and it compiles now. How do I feel? I feel like to vomit source code at the moment. Especially assembler. Now need to debug all this, but before that I'll take a break because it's my 25th birthday on Saturday..

context switch

Still working on context switching code. It's easy to design a simple system, but it is harder than I thought to design it properly. I allow irqs to preempt irqs, kernel, and userspace, which means each of these contexts must be handled properly. I have resolved almost all of it. Now I need to implement it. The only part that I'm not yet quite sure is whether I really need 2 contexts per process, one for kernel and one for userspace. Because system calls preempt.. I just realise now as I write this that I don't need two contexts. System calls push user context onto their stack, and don't write to the ktcb. When they are pre-empted, then the current context could be saved to the tcb, be it in the system call or userspace. So the rule-of-thumb is, if interrupted, save previous context on the current stack, if context switch will occur, pop it from the stack, save to ktcb context area, and load the next context. This seems to apply for all interruptions, i.e. irq->irq, usr->svc svc->irq usr->irq...
This is good fun.

Stuff implemented

KIP is implemented. Timer and interrupt controller support is added. 11 system calls can be called from userspace. (They are actually not implemented yet.) The nice thing is I can use Insight + qemu for very rapid testing. Upon running of a script Insight is started, gdb connects to qemu, loader runs, and stops right after the mmu is turned on and before jumping from physical to virtual. Then it loads the kernel image symbols, and stops. So in the convenience of running a simple script you get to step through the kernel code with Insight. Something possible theoretically but never practically with a hardware debugger. The reason is you have to configure the hw debugger, connect to target etc. etc. and debugger prompts you with its endless and needless questions at each step and it takes more than half a minute to do this. Anyway I've done other nice things but this is what I did last night so perhaps slightly influenced by it ;-). I've been doing ok so far, but overall there's just so much more to write. The next thing I'll do is finally implement the scheduling, and some of the easier system calls. (Well all seem straightforward as long as I get the register glue logic correct) Meanwhile I am looking for an embedded gui implementation. I am seriously wondering why there isn't a widely adopted replacement for X in a smaller scope. I've found something called libggl (or similar name) that looks promising. The code looks good. But not sure if it is worth spending hours and hours on it. But before I do that I must get a lot of other things done first anyway.