Home | Up | Feedback | Contents | Search

Anna K4

Home
Up
News
Company
Products
Services
People

 

The Kernel

ANNA is object oriented all through-out. It has a vertebral column made of types which we call Morphology. These types generate objects. Objects are inter-related. The workhorse of this system is the TREE construct. The back-bone is traversable.

VNC into Proxima's demonstration server:

Single processor simulation

Quad processor simulation

3D

 

The system gets loaded into RAM by a 512 bytes bootstrap loader, in itself quite a piece of engineering as it does full hard disk encryption for its size. Once in RAM, K4 trampolines into Protected Mode all the processors that it finds in a matter of 20 instructions. The first processor to
boot initializes the kernel up to the first fork of a thread. The kernel has two
facets: it is a set of most generic objects, mechanisms and principles on one
hand, it is the set of hardware drivers and primary services on the other. The
kernel owns the memory device which it manages with a rather sophisticated
hierarchical Memory Manager where sub-allocators can negotiate their frontiers
if need be, can swap to disk, and can forget. Forgetfulness is one important
memory management technique that few (if any) systems employ. Initialization of
the kernel involves all the AT devices through their dedicated kernel drivers.
All processors are initialized, idle and kernel debugger threads are constructed
for each. All processors handle hardware events as they-re driven by the PIC.
The initialization process ends with one processor, whichever gets there first,
calling the System's MAIN function. The desktop is a thread free to spawn other
threads. All hardware events and exceptions have a thoroughly planned design.
The system never clears the interrupts, therefore never blocks. There could be
an ample discussion here as to what this really means, and as to what a
devastating effect can a developer's fear of something can have on a design.
Once you clear the interrupts in one place you would have to keep doing that in
cascade everywhere. We had no fears here, and the only protective construct in
the system are the Memory Manager's and Video driver's multi-processor
spin-locks, which are sometimes needed. As a consequence, the OS permits the
demonstrably highest level of parallelism and re-entry. The price we had to pay
was to write our kernel code with extreme care as to what the implications of
re-entry would be at the boundary of each two micro-instructions that could not
be atomically executed. For this reason, there were times when development of
this kernel went at the pace of 5 instructions per day. If you aren't in the
game, perhaps this isn't clear enough. Suffice then to say that K4's kernel is
of academic quality. 

One of the prime design objectives with ANNA K4 was to ensure the shortest path between the INIT signal to launching a user application. To achieve this latter goal, ANNA exports all its classes so they may be recycled in any application program. The memory architecture is huge SELECTOR:OFFSET and protection and virtualization is achieved through segmentation. We did not buy into the FLAT memory model of Windows and Linux, consider them to be a huge mistake, and  one for which the industry keeps paying a price of learning OLE, COM, and lately .NET. OS/2 was the only other system that saw things the way we did.  What concerns us even more is that Intel, one of the finest places on Earth for thought, has succumbed to some unjustified pressure when, instead of simply scaling the offsets of the P4 processor to 64 bit, they also dropped segmentation for most addressing modes except those made through selectors FS and GS. We must lobby for a remedy, otherwise other processor manufacturers would start going that way too, for compatibility.

ANNA K4 is the parent of ANNA K5, which is now our spearhead. 

The Desktop

Kernel initialization turns into desktop initialization. At the time it was designed, the aim of K4 was not to be glossy, but to be functional. As a consequence, the desktop feels crude by today's standards when even your mobile phone has loads of pretty bitmaps and what not. One needs to make the difference between the capabilities of a system and the actual exercise of those capabilities. Although Anna runs its desktop mainly in text mode, its video driver does vector graphics too and -buffering support for 3D, with illumination, mip-mapping, and loads of others. Most importantly, is that our clipping engine is N-dimensional, capable of 3D clipping and even 4D clipping for temporal clipping as with animation. We shall discuss those matters elsewhere. What you should always bare in mind is that what you see at one time is nowhere near the full story of ANNA K4, which has an hugely complex function for its 168K size.

ANNA K4 in session

Anna K4 running a 4 CPU Pentium machine.

On of the system's most important component is the Master Browser, a window titled "System Classes" with a tree viewer that shows a hierarchy of types on the left with a list of instances on the right. If Windows lives through Explorer, then ANNA lives through this Browser.  There are similarities between our browser and the Explorer as well as differences:

  1. They both look the same, tree on the left, level content on the right
  2. They both open items for inspection by selecting the desired item.
  3. The Windows explorer works in hand with the association table and invokes the dedicated viewer depending on the type of item, so does our browser.
  4. We apply the browser uniformly to navigate to and from every corner of the system, Windows does more and more of that and would probably end-up mapping everything too.
  5. Our browser navigates anything starting with the system's morphology.
  6. The list on the right is the cumulated content of a branch in our case.
  7. Our back-bone is the top of the file-system, and this can be  another discussion.

The scenario sampled by the screenshot shows some of the system's backbone in "System Classes", particularly the four instances of the CPU type in the browser with CPU0 and the uKernel objects opened for editing. ANNA K4 is self-aware in that it knows its own data types and can construct the editor of any type.

The viewer for the uKernel on the left shows and updates in all the data fields of K4's micro-kernel The auto-sampling feature of these viewers gives the user important real-time statistics such as the history of hardware events, their dispatching along the IRQ handlers, the kernel SMP spin-lock.The uKernel is also a starting point fo further browsing leading to any other place in the system.

Viewing the CPU structure is also of great importance. The viewer on the right shows the type of the CPU in all its details down to P5 and performance information, the tasks of the CPU with their last state before dispatching. and with several configuration options that one might want to set.

The Kernel Debugger

Anna K4's kernel debugger performing a trace of the desktop thread.

The operating system features comprehensive debugging capabilities. Their quality is overwhelmingly demonstrated in certain scenarios such as the one above, where the desktop itself is being traced in animation mode. The demo proves the transparency of the system, its never-blocking architecture, and its full re-entrance capability. The CPU viewer on the right updates to the latest state of the TSS with all the registers of the Pentium processor. The system allows all processors to be traced in multiple windows concurrently. The dis-assembler knows a great deal about the processor, is colour coded, and segmentation aware.

The File Systems

Anna K4's file system browser and associated file viewer.

The kernel has support for FAT12, FAT16 and FAT32 file systems. The desktop uses the browser to navigate the file systems mounted during INIT. Once a file is located it can be opened. For viewing files, the system features either a raw hex viewer or a text editor such as the one presented in the screenshot above to the right. The text viewer is too an interesting piece as it operates on memory streams which are capable of compression. When running in tight spots, the system may turn memory compression on, in which case the editors would use a small window of memory to slide it over a run-length compressed stream. One important feature of our compressors is that they can be programmed to forget old blocks. With this feature on, we use them to build logs with no fear of running out of resources.

Hardware Device Drivers

The IDE hard disk and the floppy disk drivers of K4.

All devices can be located and edited. K4 offers a wealth of information and configuration capabilities for each type of device. When browser sampling is on, these windows also become important diagnostic tools.

The graphics engine and the 3D desktop

Anna K4 compiling rendering and animating 3D structures.

The desktop of ANNA K4 and the Kernel's video driver have native 3D support. All windows are in fact cubes, all graphic elements have a Z position. This means that an editor can coexist with a 3D structure, and can both be blended into the video-driver's z-buffer. The screenshot above was taken from an application of ANNA K4 that also links with a compiler for Berkley SAP definition texts, which is not natively supported by K4.

Remote control and terminal services

The desktop of ANNA K4 is recursive. One may open new instances of the desktop in separate windows. Any object can be remote controlled from the system browser by piping the keyboard into it. The text-mode desktop can be driven out over the serial communications to an ANSI terminal. ANNA K4 is natively multi-user. One desktop can connect to various other computers and acquire desktop sessions to it.

ANNA K4 In a nutshell

This OS is the accumulation point of a tremendous amount of core technology, has a wealth of features, the tightest most elegant design and the tiny 168K footprint.

The future of K4

It would be hard to believe that K4 can be superseded by anything better. But it's true. For the last decade we've been developing a much more radical operating system that would soon replace some of K4's core mechanisms with something significantly better and looking at the state of today's technology it already is 2 generations ahead. The K4 development both benefited and suffered from the choice of TASM as the tool to build it. The benefit was that we got the taste for miniature and got to excel at it. The draw back was that we ran out of TASM's symbol space. The disadvantage isn't really a stopper for K4 development, but it made us realize that we need our own development tools. ANNA K5 is a new programming language and development paradigm, and a much more sophisticated and complete runtime engine. But K5 is still work in progress.

Of K4 we will surely keep the Protected Mode logic and the device drivers hierarchy in the form of the Mini-Kernel. Everything else has changed beyond recognition.


Information Request Form

Select the items that apply, and then let us know how to contact you.

Have a representative contact me
Other

Name
Title
Company
Address
E-mail
Phone
Comment

Hit Counter

Home | Up

Send mail to webmaster@ProximaCentauri.ro with questions or comments about this web site.
All principles and artwork exposed on this site or by our software products is our intellectual property. 
Copyright © 2006 Proxima Centauri Romania SRL. Last modified: 05/27/09