Ada Sources Object Code
Executable
GNAT
Front-end Back-endGNAT Binder Linker
GNAT Run-Time Library
Figure 5
The GNAT compiler chain.
Consequently, a flexible Ada run-time requires the: ▶ ability to create subsets of the run-time;
▶ use of operating system services common across a wide range of mul- tiple operating systems; and
▶ awareness of the differences in these services.
GNAT achieves this flexibility by: resolving run-time entities at compile time; defining a common low-level interface; and providing target-specific versions of run-time packages.
As GNAT compiles an Ada package, the compiler front-end inserts run-time entities — constants, subprogram calls and types— into the package’s code to realize the desired dynamic semantics (Schonberg & Banner, 1994). GNAT loads the library packages containing theses entities dynamically at compile time using the Rtsfind package (Free Software Foundation, 1992). Part of Rtsfind is a check to ensure the inserted entity and the package housing the entity exists within the run-time library. If the check fails, with GNARL built as a configur- able run-time, GNAT raises a compile time error at the point in the user’s code where the entity is required.5
Thus, Rtsfind enables the safe use of GNARL subsets independent of the Ada front end by discovering what the run-time library supports as the front-end processes the user’s code, allowing a single compiler to support multiple run- time subsets (Schonberg & Banner, 1994). GNARL subsets are then simple to create by removing GNARL packages not relevant to the user’s application (AdaCore, 2015c).
The ubiquitous nature of C allows GNARL to access many operating system services in a portable, platform independent manner through the C standard li- brary (AdaCore, 2015c). Services include: memory allocation and management, file IO, and maths functions. Missing from the C standard library until its 2011 revision was support for accessing the operating system’s task services (ISO/IEC, 2011). While a standard for accessing an operating system’s task services exists in
the form of POSIX (a standard for a portable operating system interface), unlike the C standard library not every operating system natively supports or prefers POSIX Threads. For example, operating systems like Windows provide their own threading interface while Solaris prefers its own threading library. Even among operating systems supporting POSIX threads, differences exist due to the standard providing room for differing levels of compliance, interpretation and private extension (IEEE Computer Society, 2008).
GNAT Low-level Library (GNULL, formally GNU Low-Level Library) provides GNARL a common, portable interface to an operating system’s tasking services (Giering, Mueller & Baker, 1994). Sitting between GNARL and the underlying operating system (Figure 6), GNULL accords an operating system independent set of low-level tasking primitives from which GNARL builds its tasking run-time upon: primitives influenced by the POSIX real-time API (Baker, Oh & Moon,
5. GNAT will throw a fatal error if the run-time is configured as a standard run-time.
run-time entities resolved at compile time
GNAT low-level library
79 REVIEW OF GNAT FOR BARE BOARDS FOR REAL-TIME SYSTEMS
1997). GNULL then maps these primitives to the underlying operating system services. Operating systems implementing POSIX Threads permit a straight- forward mapping, with GNULL acting as a lightweight wrapper. Other operat- ing systems, like Windows, require GNULL to perform more work to connect its interface to the underlying services (AdaCore, 2015a). The use of GNULL ultimately constrains the implementation of GNARL’s tasking services; whose primitives dictate the strength and weaknesses of resulting tasking services. The last component making GNARL a flexible run-time is the capability to pro- vide target-specific packages (Baker & Giering, 1996). For example, the System. Task_Primitives.Operations package provides the tasking primitives interface. Each target requires a separate package body mapping these primitives to the underlying target’s services as shown in Figure 7.
No tasking s-taprop-dummy.adb Windows NT s-taprop-mingw.adb HPUX 10 s-taprop-hpux-dce.adb Bare Board s-taprop-xi.adb Linux s-taprop-linux.adb POSIX: s-taprop-posix.adb Solaris s-taprop-solaris.adb VxWorks s-taprop-vxworks.adb System.Task_Primitives.Operations
target variants for s-taprop.adb resulting s-taprop.adb for VxWorks s-taprop.adb
rename
When the run-time is built, the build system renames the corresponding target package to the correct package file name: for example, compiling GNARL for VxWorks would see s-taprop-vxworks.adb renamed to s-taprop.adb. The file renaming occurs as part of GNAT’s build system, which contains the mappings between target packages and their targets (Free Software Foundation, 2014). Target specific packages delivers GNAT the ability to customise any file mak- ing up the run-time — as long the public interface of the package remains unchanged. GNAT typically constrains customisation to library packages con- necting the run-time library to the underlying operating system, accounting for the differences in how these systems provide their services.
target-specific versions of run-time packages
Figure 7
Targeting run-time packages for different systems.
Figure 6
GNAT Run-Time library architecture.
GNAT Run-Time Library (GNARL)
C Standard Library Threading Library GNAT Low-Level Library (GNULL) Application Operating System Processor 80 CHAPTER 4