into the system as required. The only possible way to implement plug-ins in
Oberon-07 is by using records containing procedure variables that pass the object
“SELF” as the first parameter.
One can consider this as a simple way of object orientation. Unfortunately, this
proved to be clumsy and error prone as an implementation of such a plugin does not
have to necessarily implement all procedures or can even assign NIL to procedure
variables, which results in NIL pointer exceptions during runtime.
This “manual” way of assembling objects also prohibits a proper analysis of the
program by the compiler and the runtime system, as the concrete instance of such
an object is assembled at runtime by the software.
A second downside of MINOS is the lack of efficient multitasking. Although the
implemented tasking scheme based on periodic tasks allows the execution of
multiple tasks quasi-simultaneously, the processor usage is suboptimal, as there is
no way to wait for asynchronous events, such as interrupts without using
time-consuming polling. This is mainly imposed by the simple scheme of using just
one stack and the necessity of a task to run to completion.
Support for reconfiguration of hardware and efficient recovery points as
described in the previous chapters are not given. Reconfigurability is only supported on the application level and recovery point is supported only on the system
level. Recovery points on the level of procedures would also be possible, as it was
already shown earlier it is a very efficient approach [6–9].
11.2 System Software for ERRIC: The Stack
of Development Tools
The obvious conclusion from the considerations presented above could be reflecting
within the language features that would meet requirements typical for developing
safety-critical systems like reliability, reconfigurability, multitasking, etc. However,
the set of requirements that a single language should satisfy seems to be too big and
even contradictory.
Also, the variety of tasks and problems that the ERRIC software should support
is quite wide: from the very basic low-level software like memory management or
concurrency support up to high-level application systems. Therefore, we need
separate tools for implementing different kinds of software.
Thus, instead of having a “single monster language for everything” with a big
number of different and contradictory features, we came to the solution of a set of
different languages each of which is suitable for a particular kind of ERRIC software.
The picture below illustrates the conceptual solution taken for the ERRIC
development tools (all language names are still codenames) (Fig. 11.1).
Each language from the stack implements a limited set of features that are
critically important just to the corresponding domain—therefore, all of them were
166
11 Programming Languages for Safety-Critical Systems
Oberon-07 is by using records containing procedure variables that pass the object
“SELF” as the first parameter.
One can consider this as a simple way of object orientation. Unfortunately, this
proved to be clumsy and error prone as an implementation of such a plugin does not
have to necessarily implement all procedures or can even assign NIL to procedure
variables, which results in NIL pointer exceptions during runtime.
This “manual” way of assembling objects also prohibits a proper analysis of the
program by the compiler and the runtime system, as the concrete instance of such
an object is assembled at runtime by the software.
A second downside of MINOS is the lack of efficient multitasking. Although the
implemented tasking scheme based on periodic tasks allows the execution of
multiple tasks quasi-simultaneously, the processor usage is suboptimal, as there is
no way to wait for asynchronous events, such as interrupts without using
time-consuming polling. This is mainly imposed by the simple scheme of using just
one stack and the necessity of a task to run to completion.
Support for reconfiguration of hardware and efficient recovery points as
described in the previous chapters are not given. Reconfigurability is only supported on the application level and recovery point is supported only on the system
level. Recovery points on the level of procedures would also be possible, as it was
already shown earlier it is a very efficient approach [6–9].
11.2 System Software for ERRIC: The Stack
of Development Tools
The obvious conclusion from the considerations presented above could be reflecting
within the language features that would meet requirements typical for developing
safety-critical systems like reliability, reconfigurability, multitasking, etc. However,
the set of requirements that a single language should satisfy seems to be too big and
even contradictory.
Also, the variety of tasks and problems that the ERRIC software should support
is quite wide: from the very basic low-level software like memory management or
concurrency support up to high-level application systems. Therefore, we need
separate tools for implementing different kinds of software.
Thus, instead of having a “single monster language for everything” with a big
number of different and contradictory features, we came to the solution of a set of
different languages each of which is suitable for a particular kind of ERRIC software.
The picture below illustrates the conceptual solution taken for the ERRIC
development tools (all language names are still codenames) (Fig. 11.1).
Each language from the stack implements a limited set of features that are
critically important just to the corresponding domain—therefore, all of them were
166
11 Programming Languages for Safety-Critical Systems