Fenix is a project which aims to make it possible to let GEM, the OS of the Atari ST/STE/TT/Falcon to live on. It was initiated by Sven Karlsson of Istari Software.
Project start: 960412
News added:
Fenix is a total remake of GEM,BIOS,XBIOS and MiNT. Why should anyone make a new MiNT?
Fenix will support theads,virtual memory at kernel level and a very fast message passing scheme.
Fenix is very influenced by mach 3 and thus consist of a very little nanokernel which only handles context switching,paging, monitors, semaphores, lowlevel memory allocation and deallocation, server and shared libraries and message passing. Everything else is handled by threads, called servers, external to the nanokernel. This means that the nanokernel lies in resident memory and the rest is in virtual-memory. An additional benefit is that this scheme increases the portability of the OS.
In MiNT and Unix a process consist of a context and a memoryspace. This means that it is hard to have several contexts running in a program. Nearly all of the new OSes have threads instead of processes. A thread is basically a context. A unix process is emulated in Fenix by a single thread in a single threadgroup in a memoryspace. The concept of threadgroups is also used. A threadgroup is a collection of related threads ordered hierarcly ie there can be groups in a group.
Programs in Fenix originally consists of a memoryspace and a thread. Additional threads can be spawn by all threads and don't need to be copies of the spawning thread.
This is a new concept. In MiNT there is no need for this since all memory is bound to processes. Memoryspace is only a collection of memoryblocks that some threads can run in.
The backbone of Fenix is messages. "interprocess"-synchronization and communication are performed by messages. A message in fenix consists of a number of 32-bit registers.
A message is sent to a port that the recieving thread have created and is listening to. This is very similar to mach. The ability to bundle ports into sets that mach have is not used in Fenix. All ports are referenced by handles, which is the same as capabilites in mach, similar to filehandles. The handles are stored in the memoryspace and are thus shared by all threads that are executing in that memoryspace.
Ordinary semaphores and monitors is used to syncronize threads running in the same adressspace. There is also a possibility to make monitors and semaphores global or shared so that threads from many adressspaces can use and share them.
On TOS/MiNT shared libraries has been a sort of mythical creature. Many have wondered if it is possible to use them others has just ignored the teorethical questions and implemented different schemes. Fenix has support for shared libraries in the kernel. OS-calls is meant to be library calls that can if necesserily post a message for a server if the call cannot return immediately.
It is vital that the nanokernel is small and has all the necessarily mechanisms to handle context switching,paging, syncronization, basic memory handling, shared library and message passing. I believe that this is sufficient:
All other activities are handled by servers which have more or less access to the memory of the microkernel. The communication to these servers are usually handled by messages or by shared library calls.
The nanokernel is very small about 4-8k of code written entirely in assembler for size and speed reasons. The amount of resident, ie non virtual, memory is also small about 8k. The nanokernel consists of four parts.
Only the pager and the swapper needs to be threads and even these do not need to be true threads and communication can be faster because the threads are in the nanokernel. The nanokernel must be assembled to the computer that it is running upon since contexts are saved differently on different processors. On a 68000 for instance there is no need for the pager and the swapper.
Here are some internals for spec freaks:
Developer documentation is currently being written since I believe that the current kernel is the final one.
I foolishly said that the kernel would be finished in late April 96. It actually was but then I also began looking into integrating support for Java and Inferno in the kernel. I soon realised that incoperating these features meant that the kernel needed to be completely rewritten. There have also been some more revisions of the kernel after that depending on various good features that I wanted to include. The current revision is the 7th one and is much more modular than the previous ones. It is also even faster than before.
The kernel have been delayed a lot due to many restatements of goals and rewrites that followed. The kernel is now finally finished. However, I will not make it completely free until I know it's really stable. It is not unstable but I want to implement more of the core system so I can test the kernel with real programs. Also the kernel is being ported to PPC for the Tempest accellerator.
Here are a list of servers and libraries:
Goodies that can be implemented into Fenix are memorymapped files, dynamic linking and... If something is needed write a server!
Fenix should be and must be highly portable. That is however no reason to do things slow. Things that must be really fast must be coded in assembler. We must make the common case fast a la RISC processors. Fenix is meant to be a fast and slick OS that is small, powerful and easy to extend by new servers and libraries. I think that we must face the fact that we must port fenix to PPC or another processor about the same time as it is beginning to work on the 680x0. We must bear this in mind but also make good solutions to problems. We cannot rely on more powerful processors with every new version like microsoft.
Fenix is currently implemented in C and assembler. Some minor parts are written in C++. There is currently no competition to these languages.
Mail me at the adress below!
Sven Karlsson Istari Software email:sven@it.lth.se