PRIORITIES AND INTERRUPTS

5.2.1 Use of Priorities

Priorities can be specified in the header of a module. They are allowed in program and

implementation modules, as well as in local modules declared inside of another module. Priorities are used to control the occurrence of interrupts. When no priority is specified, all interrupts may occur.

However, when a program is running at a certain priority, only interrupts of a higher priority will be accepted. At the highest priority all interrupts are disabled. Note also that running at the lowest, specified priority is very different from running without any priority.

A priority module is entered upon the execution of its module initialization code or upon a call of an exported procedure. A priority module is left upon return from its initialization code or upon return from an exported procedure. When entering a priority module, the interrupt control system

(hardware and software) is set such that interrupts of a priority lower or equal to the one specified in that module are not passed to the processor. When leaving a priority module, the interrupt control system is reset to the state it was prior to entering that module. The procedure 'LISTEN', from module 'SYSTEM', allows a process to lower its priority temporarily. During the execution of the procedure 'LISTEN' the interrupt control system is set such that all pending interrupts are accepted.

Inside a priority module, calls to procedures of other priority modules with a lower priority than that of the module with the call statement are not allowed. When this situation is detected by the

compiler, an appropriate error message is produced (error 161). If a procedure of a module with no specified priority is called, the current priority remains unchanged. If a procedure of a module with higher priority is called, that higher priority becomes effective during execution of the called procedure. The old priority is restored upon return from that procedure.

Priorities are attached to processes. Upon a 'TRANSFER' or 'IOTRANSFER' to a process running at another priority, the interrupt control system is switched to the priority of the process which will be activated. The same holds true for the implicit coroutine transfer which occurs upon an interrupt.

PRIORITIES AND INTERRUPTS MODULA-2/86

5.2.2 Priority Levels

Both the MODULA-2/86 compiler and the MODULA-2/86 run-time support only allow for a fixed range of priority levels. Eight priority levels are supported with values ranging from 0 (lowest level) to 7 (highest level). If a module priority is specified with a value out of this range, the compiler produces an appropriate error message (error 80).

The above range of priority levels is the default for the MODULA-2/86 system. The default may be changed during installation of MODULA-2/86 as follows:

Note: To encorporate the following changes, you need the sources of the MODULA-2/86 run-time support and some compiler modules.

• Limit in the compiler

The compiler parameter module contains a variable that specifies the upper limit of the legal range. By assigning another value to that variable, this upper limit can be modified.

• Limit in the run-time support

Please refer to the assembly source program of the run-time support for the changes required to support another range of priority levels.

5.2.3 Interrupt Handling

There are three main ways to handle interrupts in MODULA-2/86:

5.2.3.1 Standard Method with IOTRANSFER

In 'standard' Modula-2, the procedure 'IOTRANSFER' from module 'SYSTEM' allows for the implementation of interrupt handlers. After the call to 'IOTRANSFER' the interrupt handler is installed and is waiting for the specified interrupt. However, on 8086 based systems, the system needs to be notified that interrupts from the corresponding device may now occur. In MODULA-2/86, the module 'Devices' provides the capability to enable and disable interrupts from a device. After an interrupt handler has been installed, module 'Devices' should be used to enable interrupts from the corresponding device.

An interrupt handler should not call the operating system, for instance to write to the terminal or to a file. If the operating system is not reentrant, such a call may crash the whole system. In general,

MODULA-2/86 PRIORITIES AND INTERRUPTS

Please refer also to the definition module 'Devices' and to the sample device driver 'InputDevice' at the end of this section. Module 'InputDevice' illustrates how an interrupt handler should be programmed with MODULA-2/86.

5.2.3.2 Faster Method with IOTRANSFER

The standard method using IOTRANSFER as described in the previous section, associates a process with the next occurrence of the specified interrupt only. The procedure 'InstallHandler' provided by module 'Devices' allows you to install an interrupt handler permanently. It associates a process, the interrupt handler, permanently with a particular interrupt. While it is not required to install an interrupt handler in this way, it may be useful for handling time critical interrupts. Installing an interrupt handler permanently improves the performance, by about 20 percent, of IOTRANSFER and of the implicit coroutine transfer that takes place when the interrupt occurs. 'InstallHandler' must only be called after the process has been created (by means of NEWPROCESS) and before the process has called IOTRANSFER. For instance, it may be called at the beginning of the code of the process.

5.2.3.3 Low Level Interrupt Handling

This is the fastest method to handle interrupts, but also the least portable. Unlike the previous two methods, this implementation doesn't perform a context switch upon interrupts, but uses the current stack to handle the interrupt. This provides a great improvement in speed because the overhead of two coroutine transfers is removed. One other disadvantage of this method is that the debug utilities do not support the debugging of interrupt service routines because the state of the stack does not have the usual form. The following code shows a module which allows the installation of a Modula-2 procedure as an interrupt service routine:

PRIORnnESANDINTERRUPTS