A built-in-support-function (BISF) for Ada software

The Air Force Wright Aeronautical Laboratories' (AFWAL) Avionics Laboratory has developed and demonstrated a built-in-support-function (BISF) for Ada software. The need for the BISF, the implementation of the specific BISF instructions, and methods for using the BISF with Ada software are described. Experiences using the BISF are reported.<<ETX>>


However,
In addition to the The Air Force Wright The development and maintenance of avionics software is assisted with instrumentation for real-time software monitoring. This instrumentation is limited to current architectures and programming languages such as JOVIAL. The introduction of Ada, in addition to new avionics architectures such as PAVE PILLAR, have placed new demands on software monitoring technology. An Ada Built-In-Support-Function (BISF) has been developed and demonstrated to support the design and maintenance of distributed Ada avionics software.
There are several features of Ada that current real-time software monitors cannot support. Dynamic allocation of memory for variables and other data types is one example. Local variable addresses are unknown prior to execution since they are stack based. For monitoring variables, current software monitoring devices need to know what memory locations to watch before the software executes.
Ada tasking presents another challenge for software monitoring. Several tasks calling the same entry before the corresponding accept statement is reached causes the calls to be queued. Debugging Ada tasks requires knowledge of how long the calls are queued, when the rendezvouses occur and in what order. Therefore, the indeterminacy of Ada tasking requires monitoring techniques that can support nonprobabilistic code.

111
New avionics systems will consist of multiple processors, distributed Ada application software, and a distributed operating system. Each of these characteristics demand additional capability from the software support tools.
Verifying that the application software works The software correctly will be a complex effort. monitoring equipment will need to trace the execution of the avionics program in real-time. In a distributed system, program tracing must take place for multiple programs running on multiple processors. With the software running in a dynamic, fault-tolerant environment the location of variables and code will be unknown prior to execution. Integrated Speed (VHSIC) speeds and limited physical signal access, existing software monitors are at a handicap.

Coupled with Very High Speed
To overcome the obstacles of monitoring Ada avionics software in real-time; Mr Duane 0. Hague, an engineer working at the Avionics Laboratory's System Evaluation Branch, proposed an Ada Built-In-Support-Function (BISF). Mr Hague called for a special class of software hook instructions that are embedded into the application and/or operating system software. The BISF instructions would transfer software hook information to a specialized BISF integrated circuit resident on the processor module that functions as an output port to the external support equipment. To the processor/ system, execution of a BISF instruction would be equivalent to the execution of a "NO-OP" instruction.
Three BISF instructions are needed to provide debugging support for multiprocessor/Ada avionics architectures. These instructions are the External Flag (XFLG), External Flag Register Dump (XFLGR), and the External Trace (XTRC).
The XFLG instruction outputs a unique flag value to the specialized BISF output port, thus making the value available to the external support equipment. This provides the capability for tracing code execution. output software performance can be measured and timing and intermittent errors can be located.
[2] I The XFLGR instruction outputs a unique flag By time tagging the flag value and the contents of a register to the BISF output port. This provides the capability to monitor stack based variables. Software test equipment can use the value of the stack pointer to add with the compiler generated relative address of the program variable to determine the absolute address for monitoring. [3] The XTRC instruction triggers the test equipment to take a limited size snap-shot of sequential processor internal bus activity such as instruction or data reads and/or writes. [4] The System Evaluation Branch of the Avionics Laboratory (AFWALIAAAF) initiated an in-house effort for full BISF proof-of-concept. Fairchild F9450 microprocessor was selected for the demonstration. Besides implementing the MIL-STD 1750A instruction set architecture, the F9450 supports the optional user defined BIF instruction (opcode 4F).

The
The F9450 implements the BIF as a three word instruction. The instruction is treated as a co-processor escape where the extension field is written to a dedicated XI0 address. mentation of each of the BISF instructions for the F9450 is shown in figures 1, 2 and 3 .
The imple-Using the BISF with Ada requires the compiler having the capability to insert machine code inline, and the assembler allowing for the BIF instruction or the capability for defining an instruction. In addition, pragma inline and pragma interface must be implemented. the BISF instructions in the Ada package MACHINE CODE can simplify their insertion.
Defining BISF instructions are inserted at points of interest in the Ada software. For example in Ada tasks, procedures, and exception handlers. A sample of Ada software using the BISF is listed in figure 4. Other areas consist of those sections of software that need performance tuning. compiler as part of the calling convention used for context changes. requires no change to Ada (MIL-STD-1815A) or MIL-STD-1750A.

Using the BISF instructions
The XFLG and XFLGR instructions were demonstrated with Ada running on the F9450 computer in the fall of 1987. Real-time tracing of a multitask Ada program was accomplished by using a logic analyzer to monitor the BISF port. timing for each Ada task was obtained by using two frequency counters. One counter measured the time between the output of the unique flag for each task. The other counter measured the average time after taking rhultiple samples. instruetioh, Local variable and tasklcontrol block locations were determined by dumping the program stack pointer t o the BISF port.

Program
Using the XFLGR To demonstrate the XTRC instruction and provide for a user friendly software test environment, a BISF Performance Monitor and Controller (PMAC) is being designed. In addition, a distributed Ada test bed will assist in demonstrating the BISF with Ada software executing on multiple 1750A computers.
There is no "free lunch" when using the BISF to support Ada software. Since the BISF is minimally intrusive, it does have a system impact.
For a typical application, execution of 10,000 BISF instructions per second would use under one percent of the processor throughput. there is an increase to the program size and a hardware cost since an additional chip and/or output pins would be needed to fully exploit the BISF. [5] Furthermore, In an Ada environment, BISF hook information is independent of virtual memory mapping, dynamic allocation, and dynamic multiprocessor multitasking. The BISF allows support equipment to determine what software is executing, on which processor, and at what time. When the cost of using the BISF is compared to existing software monitoring technology and the complexities of debugging distributed Ada, the BISF concept is seen as the best technical, least expensive answer to the issue of real-time performance monitoring.