Stella Module and Entity Linkage

 

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.

  1. The module and context structures.
  2. The module and entity linkage.
  3. The privilege structure.

The module and entity linkage mechanisms provide a means for code or data in one module to use code or data in another module. This allows complex systems (including Stella itself) to be built from small simple, well defined and easily maintainable units.

Linking and binding

As with so much jargon in the world of operating systems, the terms "linking" and "binding" are slightly misleading. Historically, "linking" has been the process of permanently binding program units together into single unit (using a "linker" or "linkage editor"). "Binding", on the other hand, has been process of the temporarily linking one program unit to another program unit (usually an application accessing an operating system facility).

In Stella there is no real distinction between linking and binding. All mechanisms for creating a connection between program units are, therefore, called "linking". The resulting connections are called linkages (not links). Note that linkages are asymmetric: they are the use by one program unit (the user) of the facilities in another program unit (the target).

Linking mechanisms

Linking is one of the nastier aspects of Stella.

Stella has nasty aspects ? - Yes. In principle, there is no need for more than one mechanism for linking or binding modules. Stella, purely for reasons of efficiency, has a number of methods.

Why ? - Because in Stella there is no real distinction between most of the operating system facilities and the applications programs using them. While this is also true of strict micro-kernel operating system designs which have a single linkage mechanism, in a micro-kernel system every communication between modules must pass through the micro-kernel. The micro-kernel concept is not only characterised by extremely high inter-module communication costs, but is also subject to implicit restrictions on the nature of the modules. Neither the inefficiency nor the restrictions would be acceptable in a Stella system.

Each method used for linking or binding is designed as a particular compromise between four conflicting requirements.

  1. Linkage efficiency. The overheads of using a linkage have an impact on the system performance when an application is executing. Permanent linkages are efficient but inflexible. User linkages are efficient but have high set up costs.
  2. Linkage set up cost. The overheads of setting up a linkage have an impact on the system performance when applications or system extensions are created or removed. Dynamic linkages have no set up costs, but are inefficient in use. Permanent linkages are fairly cheap to set up, but are inflexible.
  3. Linkage simplicity. The simplest solution is to create a linkage dynamically every time a facility is used. Dynamic linkages (not to be confused with Dynamic Link Libraries which use static run-time linkages) are the simplest to use, but they are also the most inefficient.
  4. Linkage flexibility. Certain types of linkage can have an adverse effect on the ease with which operating system extensions can be removed or changed. Neither dynamic linkages nor user linkages limit the flexibility of the system.

Core operating system modules

Core operating systems are not usually provided with any means for being removed from the system. This restriction is both fairly natural and useful.

The restriction is natural as removing a core module would require the space occupied by the module to be released for use by other software. This cannot be done, if for example, the module forms part of the memory manager or if the core module is in ROM.

Furthermore, although it is, in principle, possible to change core operating system modules while there are applications executing, the new modules would have to use the same internal data structures as the modules replaced. This facility would not be useful except for "upgrading" non-stop systems.

The restriction is useful as linkages to the core operating system modules do not have to cater for the possibility that "target" may be removed.

Permanent linkages to core operating system modules

Core operating system modules are "permanently" linked together as they are initialised. Entities may also have permanent linkages to the core operating system modules. Permanent linkages are unidirectional: establishing the linkage does not require any modification to the target.

The targets for the linkages are defined in "operating system vectors". Each target has a vector name (for example *MM, for memory manager facilities) and a facility number (the position in the vector). The header for each module defines the targets provided by that module. Several modules can contribute to a particular vector, and a module may contribute to several vectors.

The facilities provided by the core operating system modules are pre-defined even though not all Stella systems support all facilities. System designers can, however, create their own operating system facility vectors, or create modules that add to or modify the "standard" operating system facility vectors.

When a program unit is loaded either by the Module Loader or the Entity Manager, the operating system locates all the facilities required and inserts the addresses of these facilities (code, table, etc.) directly into the appropriate location in the program unit's code or data area. The facility may then be referenced directly during execution.

This form of direct linkage can only be used if there is no need to increase the privilege to access an operating system facility. This is true either if the operating system facility is not privileged or if the calling task is already privileged. Otherwise operating system facilities can only be accessed via "operating system calls" which automatically ensure that the job's privilege is raised to system level and that the call parameters are checked.

Operating system calls (with dynamic linkage)

Operating system calls can be used to access operating system facilities in a more controlled way than direct, permanent links. Where the hardware provides a "privileged" mode for operating system functions, allowing access to otherwise protected resources, operating system calls can provide a higher level of security.

This higher level of security may be useful during software development or if a computer holding critical data may be accessed by non-authorised persons. It contributes little or nothing, however, to the reliability of embedded systems, data management systems or any other system executing a well defined and reliable set of applications.

Stella operating system calls are fairly conventional. The facility required is specified by a numeric key. An operating system call is, therefore, a form of dynamic linkage where the facility is identified and located each time it is required.

There are three distinct operations.

  1. Establish privileged execution mode (usually by a "trap" or "interrupt" instruction).
  2. Establish system context.
  3. Find the address of the function in the operating system call vector and call it.

The operating system call vector is similar to an operating system facility vector, but there is only a single vector for all operating system calls. As the vector needs to be referenced on every call, the efficiency is important. A single vector is more efficient.

Establishing the system context also requires registers to be saved and the function to be located using a key. An operating system call is fairly expensive. For an MC680x0 processor, only 8 real instructions are required for the call (including the instructions in the calling code). These instructions are, however, very "heavy" and are the equivalent of 14 "nominal" instructions. For the 80x86 series of processors, the operating system call mechanism is even heavier.

The exit from operating system context is just as expensive as the entry. Overall, for a MC68020, as commonly used in embedded systems, a Stella operating system call will cost up to 8 Ás more (at 20 MHz) than a direct call using a permanent linkage.

Most operating systems only provide "heavyweight" operating system calls for accessing operating system facilities. Some "minimum" real-time operating systems, such as VxWorks, only offer direct calls. Stella offers both.

Entities

Unlike core operating system modules, entities can be removed or replaced at any time. A permanent linkage to an entity is, therefore not possible. The equivalent mechanism for accessing a facility within an entity is the user linkage.

User linkage

A user linkage is set up by the user entity "registering" its interest in the target entity. The target entity is always identified by name. There are a number of possibilities for registration.

When an entity no longer needs to use another entity, it can "free" it.

Once a usage is registered, if a request made to remove or replace an entity that is being used, either the user (or users) will be forcibly removed or the removal will not take effect until the last user has freed the entity.

This mechanism ensures that facilities in one entity can be used as efficiently from another entity as if the whole system were monolithic, but provides the flexibility to add, change and remove facilities. It is a highly efficient, uniform and coherent substitute, not only for the old-fashioned run-time library, dynamic link library and object linking concepts but also for old style device driver bindings.

Temporary linkage

A temporary linkage is a form of dynamic linkage that combines the entity registration, access and freeing into a single operation. Two forms of temporary linkage are provided.
  1. Subroutine call. A routine (identified by a name or a key) within the target entity is called with formalised set of parameters.
  2. Data transfer. Data is transferred to or from the target entity. The location in the target is identified by a name or a key. This type of linkage is equivalent to a classical distributed object access.

This type of linkage is, naturally, very much less efficient than a user linkage. There are, however some circumstances where a temporary linkage is preferred to a user linkage.

Special linkages

Some operating system modules have facilities for setting up linkages that are specific to the module. The Stella External Event Managers, for example, set up special high efficiency permanent linkages from external event handlers into the operating system.  

  Back to table of contents.


Copyright (c) 1997 Tony Tebby.