argument in procedures. Therefore, the size of these variables must be derived at
runtime.
It is interesting to see that only structured languages allow the efficient creation
of recovery points, as the scope of a procedure or in other words the visible and
accessed variables can be clearly derived. Strong-type safety that was introduced
for reliability of programming might be helpful here as in supporting the scheme of
deriving the size of all variables. For example, pointer arithmetic in C prohibits the
efficient creation of recovery points, as the whole memory can be accessed and
modified and thus the entire memory must be saved. Pointer-free languages such as
Composita of Prof. Blaeser, briefly introduced in [55], might be immediate next
step in making new language for real-time, reconfigurable, and PRE-smart systems.
Various strategies [51, 54, 56] exist how to insert recovery points in a program.
This can either be done automatically by a compiler or manually by the programmer. It is quickly obvious that a compiler should do this, as this task is not
trivial for a programmer.
The insertion strategy is chosen according to the used system and applications
and is always a trade-off between the overhead in terms of time and space and the
anticipated recovery time. Frequently created recovery points typically need more
time and space to be created, but on the other hand in case of a failure the required
recovery time overhead is small. There are no doubts that hardware support might
reduce regular overheads of recovery point formation. One example of hardware
support is discussed in the next section.
In turn, using sparsely created recovery points typically leads to a smaller
overhead but requires more time to recover as more statements have to be executed
until the next recovery point is reached [3].
8.4 Hardware Support for Recovery Point Creation
In order to keep the system overhead low, it is proposed here to implement the
actual recovery storage procedure in hardware. We introduce therefore the recovery
point unit (RPU), which represents a hardware component that is capable to create a
recovery point on a nonvolatile medium.
It should thus be able to interpret the above introduced format of a recovery
point in memory and store it. To speed up the performance and to have a measure to
detect corrupt recovery points, the RPU should be able to calculate a checksum on
the fly of the just created recovery point and store it as well together with the
recovery point. This checksum helps to identify corrupt recovery points, which
cannot be used to recover a system.
The RPU should be placed directly on the CPU bus (Fig. 8.3) and should have
direct access to the memory in order to get maximum speed for the generation of
recovery points as well as during recovery.
8.3 Recovery at the Level of Procedures
123
runtime.
It is interesting to see that only structured languages allow the efficient creation
of recovery points, as the scope of a procedure or in other words the visible and
accessed variables can be clearly derived. Strong-type safety that was introduced
for reliability of programming might be helpful here as in supporting the scheme of
deriving the size of all variables. For example, pointer arithmetic in C prohibits the
efficient creation of recovery points, as the whole memory can be accessed and
modified and thus the entire memory must be saved. Pointer-free languages such as
Composita of Prof. Blaeser, briefly introduced in [55], might be immediate next
step in making new language for real-time, reconfigurable, and PRE-smart systems.
Various strategies [51, 54, 56] exist how to insert recovery points in a program.
This can either be done automatically by a compiler or manually by the programmer. It is quickly obvious that a compiler should do this, as this task is not
trivial for a programmer.
The insertion strategy is chosen according to the used system and applications
and is always a trade-off between the overhead in terms of time and space and the
anticipated recovery time. Frequently created recovery points typically need more
time and space to be created, but on the other hand in case of a failure the required
recovery time overhead is small. There are no doubts that hardware support might
reduce regular overheads of recovery point formation. One example of hardware
support is discussed in the next section.
In turn, using sparsely created recovery points typically leads to a smaller
overhead but requires more time to recover as more statements have to be executed
until the next recovery point is reached [3].
8.4 Hardware Support for Recovery Point Creation
In order to keep the system overhead low, it is proposed here to implement the
actual recovery storage procedure in hardware. We introduce therefore the recovery
point unit (RPU), which represents a hardware component that is capable to create a
recovery point on a nonvolatile medium.
It should thus be able to interpret the above introduced format of a recovery
point in memory and store it. To speed up the performance and to have a measure to
detect corrupt recovery points, the RPU should be able to calculate a checksum on
the fly of the just created recovery point and store it as well together with the
recovery point. This checksum helps to identify corrupt recovery points, which
cannot be used to recover a system.
The RPU should be placed directly on the CPU bus (Fig. 8.3) and should have
direct access to the memory in order to get maximum speed for the generation of
recovery points as well as during recovery.
8.3 Recovery at the Level of Procedures
123