Systems Programming with the SAS/C Compiler

An Overview of SPE

The C Language and Systems Programming

The C language was originally designed for general purpose programming under UNIX operating systems. Although C was used for writing the operating system itself, the language design allowed C language programs to be relatively portable across widely disparate operating systems and machine architectures. The portability of C has recently been enhanced by the efforts of the ANSI X3J11 Committee to standardize the C language, including the run-time library.

In the systems programming environment, however, portability is not an important issue. Systems programs cannot restrict themselves to a portable view of the system. An implementation of C for this environment must provide access to system data and services without regard for other environments. It must be efficient. Above all, it must be adaptable to the requirements of the operating system.

SPE is designed to enable the C language to be used as a systems programming language in the IBM 370 environment. SPE consists of the minimum number of support routines needed to execute a C program and a small run-time library that is systems-programming-oriented.

SPE is designed to enable C programs to interface with the operating system in the same way an assembler language program does. For example, storage can be allocated with a DMSFREE or GETMAIN macro, each of which expands to the appropriate SVC instruction. SPE programs can access parameter lists like assembler language programs do. Under CMS, the SPE equivalent of the main function gets pointers to the tokenized and untokenized PLISTs as arguments, instead of using a portable format such as argv and argc .

Adapting SPE

All of the SPE routines that interface with the operating system are provided in source code. Each routine provides basic functionality in a generic manner. However, given the wide variety of unique SPE applications, no single interface can address all the conflicting needs efficiently. Therefore, these routines can be (and are expected to be) adapted as necessary for the needs of the environment. For example, if the implementation of the stack in L$UPROL is not practical in a particular environment, then it can be redesigned for that environment.

The SPE Framework: Creating and Terminating and SPE Internals contain detailed information on how each of the major SPE routines operates and what is expected of them. Each discussion is oriented toward the role the routine plays in supporting the SPE execution framework and how this framework interacts with compiler-generated code.

The Run-Time Library

The SPE run-time library is designed to support systems programs in the C language. The library contains three classes of functions. In the first class are those functions that interface directly to the operating system. For example, instead of an fopen function, SPE provides a function to open an OS/390 data set using BSAM and a function to open a CMS file with FSOPEN. In the second class are those functions that are present in the full C library but do not interface to the operating system, such as math and string functions. In the third class are those functions, such as malloc , that are present in the full C library but have operating system dependencies. The SPE library contains SPE versions of these functions that differ from the full library functions.

The SPE library also supports many POSIX functions, such as open , chdir , and fork . Most of the POSIX functions are implemented within the OS/390 control program, and support for these functions is therefore no different from the SPE support for BSAM and GETMAIN. POSIX functions that are not supported directly by UNIX System Services (USS) OS/390, such as fdopen and tzset , are in general not supported with SPE.

The SPE Library contains descriptions of all the functions that are designed for use with SPE. Each description also explains how the function is implemented. When the function interfaces with the operating system, the description gives the name of the associated source code file. In many cases, common adaptations are mentioned, along with suggestions as to how they can be implemented.

One of the most frequent applications in systems programming is interrupt handling. Interrupt Handling in SPE describes the bldexit function, which provides an interface between an operating system interrupt exit and a C program. bldexit is a prototypical SPE function in that it forsakes portability for adaptability and efficiency.

SPE and the Debugger

The SPE framework does not include support for the debugger.

Chapter Contents
Previous
Next
Top of Page