HYDROGEN: Extensibility (by alaric)
As promised, here is the second part of my series on HYDROGEN, where I will discuss extensibility.
Introduction
Extensibility is a naff name, but I couldn't think of a better single word for the requirement that a system specification should be applicable to a wide range of requirements. I'm talking about the specification itself being extensible, rather than any given actual system.
Basically, I want HYDROGEN to be useful in at least these broad classes of situation:
- Running as a standard process on some kind of POSIXy operating system, like the JVM. That may sound at odds with it being an "operating system-level virtual machine"; what sense is there in implementing an OS on top of an OS? But the fact is that the kinds of things ARGON as an OS will do are really quite different to what a POSIX-like OS will do. About the only overlap is scheduling processes, and even there, ARGON wants to do it rather differently to how POSIX does. In such a setup, POSIXy facilities such as the filesystem will be made available to ARGON applications that want them, and HYDROGEN will expose the TCP/IP stack at the BSD sockets level rather than needing a native IP stack.
- Running on the bare metal on workstation- or server-class hardware, interfacing directly with all the hardware, with lots of memory and CPUs to play with.
- Running on the bare metal on an embedded system. I'm not hoping to support tiny 8-bit AVRs with 1KB of RAM; since this environment isn't the highest priority in my plans I'm trying to enable support for low-end platforms in HYDROGEN where I can do so without hampering usefulness in the other environments, so we'll see what the smallest machine we can support will be. Currently, I'm still hoping we might be useful in a 16-bit environment with 64KB of RAM, perhaps running code from Flash memory (even with a Harvard architecture) if runtime support for compilation and interpretation is disabled. I'm looking at the sort of environments VxWorks and QNX run in.
We've already seen how we can abstract away the different types of CPU; and by starting with an SMP model, single-processor systems are just a degenerate special case. We'll be covering the widely varying ways that your code gets running on the target platform in the first place in a subsequent post. In this post, we'll discuss how we deal with widely varying hardware capabilities (or, in the case of running on POSIX, not even having access to much of the hardware at all)...
Wed 15th Jul 2009 11:05 pm 
Subscribe