|SSD16 - Linking|
LSE16 - Binden
|SSD16.I.1||Granularity||The exchange of control parameters with SWFM01 - Workflow Management is possible for individual closed function packages of the tool by means of a disclosed, documented interface.|
|SSD16.I.2||Input interface to SSD15 - Compiling||It is possible to integrate code compiled with SSD15 from the object management without further transformation in order to be linked.|
|SSD16.I.3||Output interface to SSD17 - Debugging||It is possible to transmit linked code via the object management without further transformation to SSD17 in order to realize debugging.|
|SSD16.I.4||Output interface to SSD18 - Estimating Performances||It is possible to transmit linked code via the object management without further transformation to SSD18 in order to estimate the expected performance behavior.|
It is possible to link several units into an executable load module. In this connection, the external references of the units are dissolved and its validity is checked.|
In general, the following units are linked to the target code: memory management, input/output routines, mathematical operations, exception handling (if supported by the language), scheduling of quasi-parallel processes (if supported by the language). These linked units are part of the runtime system.
|SSD16.F.2.1||Target code||It is possible to enter the file name of the target code to be linked.|
|SSD16.F.2.2||Load module||It is possible to enter the file name for the load module to be generated.|
|SSD16.F.3.1||Option||It is possible to get a linkage protocol generated by means of an option.|
This protocol contains a link map.|
The link map contains at least a list of all linked units and their corresponding memory addresses, sizes, and overlay structures (if relevant).
|SSD16.F.3.3||Details||The linkage protocol contains the relevant parameters, the valid options and the data and time of linking|
It is possible to instrument the load module with debug information.|
A load module thus instrumented can-in case it has already been compiled with the debug option-be tested with a debugger (see SSD17 "Debugging").
It is possible to specify the heap size by means of an option.|
Heap refers to the memory area for dynamically generated objects that is administrated during the runtime of the load module.
|SSD16.F.6.1||Size||It is possible to get unused code deleted from the load module by means of an option.|
Runtime routines that are not required are not linked.|
For example, if no sinus functions are used there is no necessity to link them. In this way memory area is saved.
By means of an option it is possible to initiate that the units to be linked to the load module are rearranged in a way that optimizes the time behavior of the load module.|
For example, routines belonging together are packed into hardware segments so time-consuming segment switching is avoided.
|SSD16.F.6.4||Frequency of utilization||By means of an option it is possible to specify that a unit is rarely utilized at runtime. Such a unit needs not be memory-resident.|
|SSD16.O.1||Upward compatibility||It must be possible to process objects generated with an older release of the tool with the later release of that tool, without loss of information and functionality.|
|SSD16.O.2||Procedural command language||The tool has a procedural command language that can be applied by the user to generate and run macros or procedures.|
|SSD16.O.3||Complexity||There is no limitation of the complexity caused by the tool itself.|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|