September 16, 2007

Hey! Where is my dos.library??

I have been fighting with 64-bit world and our build system again :) Cannot tell which of them is better or worse in terms of debugging and hunting for undefined behavior ;)

I have provided you another log (well, call this debug output a screenshot if you like). What you may see here is a list of modules present in kernel (remember, some of them have been loaded separately, by GRUB) and a very early startup process of whole AROS. The new and interesting things are timer.device, irq.hidd and ata.device.

The timer.device is a straight recompilation of x86 version. It still does not use the local APIC driven by at least 66MHz source, but uses an ancient 1193180Hz timer. It will change very soon since the new APIC timer has been proven to work properly on AROS. I need some spare time to implement it in timer.device now. There were two more "cosmetic" changes - the timer.device checks the SysBase->Elapsed field and reports forced reschedule if needed. Additionally, timer.device uses kernel resource to add/remove it's interrupt handlers.

The irq.hidd is a simple wrapper for kernel.resource. Used to add and remove IRQ handlers. Nothing less and nothing more. Boring, huh?

The ata.device compiled with some minor issues. First of all, the MakeDosNode function of expansion.library has been changed. The input packet is an array of IPTSs now (it was array of ULONGs previously, which are not suitable for 64-bit system). The other change was the way ata's internal tasks were initialized. I have sent them some parameters through the stack, which is not valid on x86_64 system anymore. Therefore, I have had to change the AddTask calls to the NewAddTask variants, with parameters passed through a TagList. You may see the result on screenshot - two internal tasks of ata.device are added and started. They do something and then wait for input...

Yes, you're right. 64-bit AROS multitask already :)

PS. You may ask about this nasty GURU down the screen. Well, it puzzled me a bit until I've found it. It's a BootStrap which cries loud that it could not open the dos.library :-) So, where's my dos.library, dude???

September 5, 2007

AROS64 - report

Hello there!

It has been a very very long time since I wrote anything last time. I Hope you still visit this site :)

Since I was very busy with my work at Uni, I have abandoned idea of writing new kernel by myself, only. Sure it would be nice to do something like that alone, but I'm afraid I would end up with a half-ready kernel, a patchwork which would be big enough to let exec.library work. Nothing less, nothing more.

The plans have changed. I will make a quicker amd64 port - a slightly modified x86 version for amd64 cpu. The old concept reborn. The huge disadvantage is (yes, you will be disappointed now) that the new kernel will offer almost nothing more than the x86 one. That means - all applications will still run in one huge address space common to all processes. It's still the fastest possible approach on x86_64 architecture - some 2 MiB pages covering the very first 4 GiB address space - all of them in translation look-aside buffer (TLB) of the CPU. The SysBase pointer is still at absolute address 4, but it's use is deprecated. One should access the CPU-local SysBase variable at address %GS:8.

What are the advantages, will you ask? Well, have a look at the screenshot. The core libraries are already there. The scheduler should work, at least in theory :). Many libraries and modules may be already compiled thanks to the enormous effort of Henning Kiel, who fights with badly written sources and let them compile. Once irq.hidd and timer.device are done, I should have AROS working on amd64. Neato, huh? Apart from that, I have avoided assembler code as much as possible. Even interrupt and exception handlers are pure C called by very small context-saving asm stub.

As soon as the x86_64 port of AROS will be ready (and bounty will be satisfied), I will start project aiming at creation of new kernel for our OS. I promise.