Hobby OS projects (by alaric)
I've written a bit about ARGON on this blog before, and the ARGON web pages at www.argon.org.uk has a rather complex (and in places outdated) summary of the major components, but I'll now write a simple explanation of how it works which, with the next shipment of [[wikipedia:round tuit]]s, I'll tidy up and put on the site.
From an implementation perspective, ARGON all balances on top of a hardware abstraction layer / VM called HYDROGEN. I've defined this as a FORTH dialect, because FORTH is renownedly easy to port to new architectures, and nonetheless quite efficient, being much more low-level than a Java virtual machine. It's really quite well-described as a portable assembly language, albeit with high-level features that make it quite a bit more pleasant to use than that explanation would suggest.
However, the ease of portability arises from a very simple basic instruction set. That means it won't make good use of advanced features of CPUs like SIMD instructions. To solve this problem, I'm defining quite a complex set of high-level instructions for dealing with a wide range of data types - signed and unsigned eight, sixteen, thirty-two, and sixty-four bit integers, word-wide integers (whatever the underlying word size is), double-word-wide integers, pointers, and Unicode characters. And a set of basic instructions for vector operations, to use those SIMD instructions or smart DMA units. There's hooks to make it possible to transparently access non-uniform memory (from good old EMS and XMS from the DOS days, or more pertinently, the fact that PAE capable x86 processors can access more physical memory than can fit in HYDROGEN's flat address space model) - a generic cache interface allows blocks of memory to be cached under a name, and then retrieved by that name, with the implementation having the option of dropping cache blocks based upon their priority metadata and access patterns; implementations may store this cache in normal RAM if they do not have any second-level memory to utliise. And so on and so on.
However, my initial implementation will be written in very basic standard C. It'll be a minimal implementation of the core instructions, along with a portable standard library implementing all the other instructions in terms of that minimal core. This C implementation will be highly portable and easy to compile (more so than GFORTH, alas, to meet my requirements, although I'll borrow a lot of ideas from GFORTH!). This will make it easy to get HYDROGEN running on top of other operating systems, or on bare hardware. It won't be the most efficient implementation, but it'll work.
This can then be a base for implementation-specific optimisation. Generation of native code for various processors. Rewriting of the standard library in raw assembly language, or to use special hardware. Etc.
The HYDROGEN hardware abstraction is designed to be complete; as well as one or more CPUs that can execute the instructions, the platform provides a unified abstraction over various boot systems (making the task of installing a new version of the bootstrap loader, native HYDROGEN implementation, or ARGON OS portable, even though bootstrap loaders and HYDROGEN implementations are platform-specific), and a tree of devices, with each device providing a number of standard interfaces - byte stream I/O, an IP address, raw Ethernet interface, a graphical display surface, etc; device drivers should generally be written in HYDROGEN itself, so they can be shared between implementations that use the same devices much like NetBSD's drivers.
Sun 16th Jul 2006 12:15 am 
Subscribe
By James, Thu 18th Dec 2008 @ 11:13 am
So whens the release? 😛 Wouldn't mind testing this thing with a couple of old forth apps I got kicking around on my drive. -Jim