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.
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.
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).
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.
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.
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.
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.
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.
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.
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.