The structure of a Stella system is highly pragmatic. There are three aspects of the structure that have a major influence on the flexibility, the efficiency and the robustness.
Stella "core modules" form the core of a Stella system. These core modules provide the basic facilities of the operating system: the management of common resources and communications within the system.
All other facilities, whether they are considered to be extensions to the operating system, utilities, drivers or applications are provided by "entities".
The distinction between these two levels is related to the old barber paradox: in the town where all men are shaved by the barber and no man shaves himself, the barber has to be a special case. Because entities can be freely created, replaced or removed, the management of these entities cannot be entrusted to another entity.
An entity is merely something (data, code, context or a combination of the these) that is known to and identifiable by the operating system.
In this diagram, the modules become increasing specific to an individual system (hardware environment or applications) as you move up through the levels. The highest level of flexibility is required at the highest level.
With the exception of the bootloader, all Stella modules have a uniform structure. A module comprises code and initialised data. The module starts with a header that defines the facilities required by and provided by the module and any initialisation that is required.
A complete system is built simply by concatenating the modules required - the bootloader ensures that all the modules are linked as they are loaded.
While it is, in principle, possible to change the core modules in a live system, this process is subject to such restrictions that it not currently supported.
Entities can own or use other entities. The operating system keeps a record of all the other entities that are owned by a given entity and all the other entities that are using a given entity. These twin "ownership" and "usership" properties are the keys to the dynamic reconfiguration of applications and operating system extensions that give Stella its flexibility.
An entity in the form of a "job", executing under control of the scheduler, requires a job context. The job context is the data area, within the entity, used by the task manager. In the most streamlined versions of Stella, the job context is no more than a save area for the registers (saved while it is not executing) and its status (priority accumulator, timers, events, etc.). In "heavier" versions of Stella, the job context is extended to include save areas for the other hardware facilities (floating point units, memory management units, etc.).
Transient tasks, such as external event handlers, do not require an extended context.
Type of entity | Working data | Fixed data | Code | Job context |
Shared or common data | Yes | Maybe | ||
Protocol definition | Yes | |||
Protocol handler | Yes | Yes | ||
IO device driver | Maybe | Maybe | Yes | |
IO channel | Yes | |||
External event handler | Yes | Maybe | Yes | |
Utility | Maybe | Yes | ||
Job | Maybe | Maybe | Maybe | Yes |
Entities themselves can be created in two different ways.
The purpose of a thread is to allow more than one task to share a "heavyweight" context and thus break the one to one to one relationship between programs, tasks, and contexts.
The purpose of an object is to provide a reduced encapsulation that excludes the execution properties of a task. This means that several objects, each with its own context, can be used within a single task, providing a level of modularity and structure within otherwise amorphous program environments.
Threads and objects are two very small steps in the direction of Stella. In Stella, each entity has its own context. Indeed, an entity could be considered to be the physical representation of a context. Rather than an arbitrary collection of heavyweight contexts (processes), lightweight contexts (threads), and taskless contexts (objects), in Stella any context may have any combination of code, data and properties.
In this illustration of a simple job structure, job 1 has a context independent of all other jobs. Job 31, however, is owned by job 3 and, therefore, automatically has the right to use job 3's context as well as its own. Likewise, both job 21 and job 22 are owned by job 2 and can use job 2's context as well as their own. Job 21 and job 22, however, cannot use each other's context (unless they request permission by registering as "users").
Unlike processes and threads, the ownership concept of context sharing is recursive. Thus job 221 and job 222 are independent of each other, but both have the right to use the context of job 22 and job 2.
This job structure allows co-operative jobs to share data and code within the context of a common owner. Job 221 and job 222 do not need any code or data of their own, they can use the code and data belonging to job 2 or job 22.
It might seem odd that only the bottom jobs of a tree have complete privacy, but this is a natural consequence of the Stella self cleaning entity management. When an entity is removed, all the entities that it owns are also removed. As entities that it owns are the only entities with an automatic right to share its context, all other entities with an automatic right to share its context are automatically removed.
"Incomplete" contexts can be combined permanently or temporarily to produce complete contexts. For example, an operation to read some data from a file requires the device driver to be able to access the calling job's context (the destination of the data) as well as contexts internal to the filing system (the source of the data and the transfer mechanisms). All these contexts, except the operating system, are defined by entities.
Each context in this example has a good reason to be separate.
In a working system, there will be many contexts at each level. For an operation via a particular channel, a particular combination of contexts is required.
The freedom with which contexts can be combined in Stella provides the simplicity of system design that is one of the fundamental bases for its unparalleled accessibility.