[Ada Information Clearinghouse]
Ada '83 Rationale, Sec 16.7: Low Level Input-Output

"Rationale for the Design of the
Ada® Programming Language"

[Ada '83 Rationale, HTML Version]

Copyright ©1986 owned by the United States Government. All rights reserved.
Direct inquiries to the Ada Information Clearinghouse at adainfo@sw-eng.falls-church.va.us.

CHAPTER 16: Input-Output

16.7 Low Level Input-Output

Low level input-output facilities are especially needed in embedded computer systems, since signal processing and interaction with non- standard peripheral devices are common. Clearly, major system dependences cannot be avoided in this area. At best the language can provide a set of standard calling conventions for dealing directly with peripherals. The specific device and data descriptions cannot however be given.

Interaction with peripheral devices involves three kinds of action: starting an operation on a device, interrogating the status of the device, and waiting for completion of an operation. The third case can be dealt with by the entry mechanism, coupled with the specification of an address clause that links the entry to an interrupt. The first two cases, however, constitute requests from the program. For these, two procedure names are introduced: SEND_CONTROL to start an operation, and RECEIVE_CONTROL to interrogate the status. Each takes two arguments: DEVICE identifies a particular peripheral device, and DATA corresponds to the information that should be exchanged with the device (hence DATA is an in out parameter).

For the definition of such procedures we are faced with two problems: efficiency and generality. Efficiency dictates that an operation that normally requires a small number of machine instructions should not be surrounded by lengthy checks. This could be achieved by making the low level primitives built-in to a given compiler. However, generality requires the ability to write the appropriate SEND_CONTROL and RECEIVE_CONTROL operations whenever a new device is added to the system, without forcing a recompilation of the compiler. Hence these operations cannot be built-in.

In order to satisfy these apparently conflicting goals, subprogram overloading and code statements can be used. As many device types should be introduced as are required by the interfacing conventions of the system. Similarly, for each device type, appropriate data types should be introduced. For each meaningful combination of device type and data type, overloaded definitions of SEND_CONTROL and RECEIVE_CONTROL can be given, and the corresponding subprogram bodies may use appropriate code statements.

The general form of the package LOW_LEVEL_IO is as follows

package LOW_LEVEL_IO is
  -- declarations of different device types
  -- declarations of different data types
  -- declarations of overloaded procedures for these types:
  procedure SEND_CONTROL (DEVICE  :  device_type;
                          DATA    :  in out data_type);
  procedure RECEIVE_CONTROL(DEVICE        :  device_type;
                          DATA    :  in out data_type);

Thus if a user needs to introduce a new device, then the appropriate types and procedures can be added independently of existing ones; this only requires recompilation of the package LOW_LEVEL_IO.

Address any questions or comments to adainfo@sw-eng.falls-church.va.us.