| M1750 Ada Technical Summary: For mission-critical applications | ||
|---|---|---|
| Prev | Chapter 6. Cross-Compiler and Run-Time Interfacing | Next |
M1750 Ada includes a run-time system that supports C and Ada. This includes the basic functions that are common to both languages, such as program startup, exception management and low-level input/output. In addition, each language is supported by a number of standard libraries, as required by the language definition.
The Ada main program is given a stack, where the location and size are determined by the linker script file. The stack is used to support subprogram calls, and typically contains a linked sequence of stack frames that contain saved registers and subprogram data.
Each task has a stack that is allocated at elaboration time from the free memory declared in the linker script file. If insufficient free memory is available, then the predefined exception Storage_Error is raised.
Interrupt handlers use a separate stack also declared in the linker script file.
The subprogram calling convention is common to both supported languages, which makes it possible to build programs using a mixture of Ada and C.
Register saving. M1750 Ada uses the caller-save convention for saving registers across subprogram calls. This convention has the advantage that the register allocator can take the call into account and reduce the number of registers to be saved.
Parameter passing. Up to 12 words of parameters are passed in registers R0 to R11. Any further parameters are passed on the stack. For a function, or a procedure with a single out parameter, the result is passed out in register R0.
The call instruction. M1750 Ada uses the SJS instruction to call a subprogram. The link is passed on the stack.
Subprogram entry. For subprogram entry, the compiler generates code to establish a new stack frame. This may include code to check for stack overflow. The compiler is able to recognize several special cases where the worst-case code can be improved. In particular, for "leaf" subprograms that have no need for stack frame data, the stack frame is completely eliminated and the code to set up the frame, and remove it on exit, is not generated.
Subprogram exit. For subprogram exit, the compiler generates code to remove the current stack frame, and return to the calling subprogram.
The return value. Function values are returned in a register if possible. If not then the calling subprogram allocates space in its stack frame then passes the address of the space to the called subprogram, which copies the function value to that address.
The following table shows the number of bits in the data representation for the M1750 Microprocessor.
| Type | M1750 Microprocessor |
|---|---|
| Integer | 16, 32 and 64 signed |
| Modular | 16, 32 and 64 unsigned |
| Fixed | 16, 32 and 64 signed |
| Floating Point | 32 and 48 |
| Enumeration | 16 and 32 |
Storage allocation for array types is simply the number of components multiplied by the allocation for each component. Components can be packed and bit aligned in some cases. Unconstrained arrays have a descriptor with lower and upper bounds for each index. Note that dynamically unconstrained arrays are prohibited.
Storage allocation for record types is the sum of the individual component allocations, which are byte aligned by default. Components can be packed and bit aligned in some cases.
The pragma Pack causes pack-able array and record components to be allocated in adjacent bits without regard to byte boundaries.
M1750 Ada supports a limited form of Ada tasking that permits static tasks, protected types and a limited form of rendezvous. The features supported may be further restricted by use of individual restrictions, or by the pragma Profile.
The general strategy is for the compiler to translate Ada tasking operations into run-time system calls, using data types from the predefined package XGC.Tasking.
Some language features (delays for example) are supported by child subprograms.
In addition the package XGC.Preemption_Control is required to give the run-time system exclusive access to the tasking data structures.
The above packages are only included in an application program if the corresponding language features are used. A null program is linked with only the minimal run-time system module art0.S.