Duo Programs

MARK Duo programs have the same issues as STANDARD duo programs. Some of these issues are listed below.

---

Ada is the Main Subprogram

A MARK program may reference C/C++ functions. The main subprogram must be written in Ada, the board support package must be initialized, as well as the Ada runtime.

---

Ada Calling to C Imported Functions

When calling from Ada to C use the Ada95:

pragma Import(C, C_Function, "c_function");

Special code is generated at the Ada call site to invoke imported C functions. On some architectures, code to initialize the processor to known state after the call to C_Function is required.

For example, when calling imported C Code on the PowerPC, the additional instruction mcrxr is generated to clear sticky exception bits that might erroneously fire Ada exceptions at some later point as shown below:

026d64:  bl            026e8c -> c_function
026d68:   mcrxr          cr7

Use the pragma Calling_Convention to configure other special code generated at the Ada call site. For example, if the C/C++ code is doing floating point do not forget:

pragma Calling_Convention(C_Function,Floating_Point_Status_Preserve=> True);

This causes additional wrapping code to be generated around the C/C++ call site to save the floating point state that is valid for Ada processing and initialize the floating point unit for C/C++ processing. Rounding modes and exception conditions are often different between Ada and C.

For example, when calling imported C Code on the PowerPC the floating point state is first stored away and then the floating point state is initialized from the global variable __FP_CONTROL_FOR_C (configured in the v_usr_conf package) before the call to C_Function. After the C_Function returns the floating point state is restored.

This is shown below by the code fragment for calling the imported C function "cio" below:

      00030: lis           r12, 0         r12 <- 0 @__FP_CONTROL_FOR_C
      00034: lfd           fr1, 0(r12)    fr1 <- 0(r12) @__FP_CONTROL_FOR_C
      00038: mffs          fr31
      0003c: mtfsf         0ff, fr1
      00040: bl            0 -> C_Function
      00044: mtfsf         0fc, fr31
      00048: mcrxr           cr7

---

Exported Ada Called From C Functions

When calling from C to Ada use the Ada95:

pragma Export(C, Ada_Function, "ada_function");

The Ada compiler generates stack checking code. When an Ada procedure is called from C, it is assumed that the stack limit needs to be initialized. A call to a runtime function to initialize the stack limit is generated in the prologue code for the external Ada subprogram.

For example, the PowerPC keeps the stack limit register in the r14 register and the prologue code stores away the existing r14 value before initializing it from the runtime call to TS_RELOAD_STACK_LIMIT_REG. The epilogue code restores the r14 register back to it's initial value:

00210: stw           r14, 0c(r1)       r14 -> 12(r1)
00214: bl            0 -> TS_RELOAD_STACK_LIMIT_REG
00218: addic         r12, r1, 010
0021c: addic         r11, r1, -040
00220: twlge           r14, r11

Pragma Calling_Convention(Ada_Function, Stack_Limit => Defeated) can be used to initialize the PowerPC r14 register to 0. Stack_Limit => None can be used leave the r14 register untouched. The Rational C/C++ PowerPC compiler does not use the r14 register.

There is often a floating point state that must be initialized to particular values for Ada code to execute correctly. This is done in the prologue of the External Ada subprograms. The state may need to be restored in the epilogue.

If the Calling_Convention specifies Floating_Point_Status_Preserve => True, then the prologue will contain:

000c4: lis           r12, 0            r12 <- 0 @__FP_CONTROL_FOR_ADA
000c8: lfd           fr1, 0(r12)       fr1 <- 0(r12) @__FP_CONTROL_FOR_ADA
000cc: mffs          fr2
000d0: mtfsf         0ff, fr1

And the epilogue will contain the restore code:

000d8: mtfsf         0ff, fr2

The __FP_CONTROL_FOR_ADA is configured in the V_Usr_Conf package and will not normally require adjustment.

---

Ada Duo Rational Executive Issues

MARK Duo programs have the same issues as standard Rational Executive Duo programs. Some of these issues are listed below.

• C/C++ malloc/free is layered on top of the underlying Ada runtime allocation mechanism. The malloc is a skin over the symbol AA_NO_EXCEPTION_GLOBAL_NEW and the free is a skin over AA_GLOBAL_FREE.
• C++ static constructors are executed before Ada elaboration.
• C++ static destructors are executed after Ada finalization.
• The C/C++ io system has the same general problems as the Ada I/O system. In addition, C/C++ io is layered on the predefined I/O implementation through the C_Support package in the c_support.ss subsystem. Duo programs using C/C++ have the following issues:

  a . must 'with C_Support;'

  b . must not do any C/C++ io until the C_Support package and predefined packages have been elaborated.

  c . C/C++ io in C++ static constructors is not permissible.

---

MARK Duo Issues

The malloc/free are supported in storage_management.ss. Even the .sm0. implementation supports malloc using AA_NO_EXCEPTION_GLOBAL_NEW on the runtime allocate only functions. The free calls are simply ignored. See the sm0 Description for more information.