![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Configuring the User Library Configuring the user library is optional. Under most circumstances, Apex functions properly without changes to the default configuration. However, enabling special features, customizing runtime behavior for your application, or implementing runtime trade-offs, for example, "fair" scheduling over deterministic performance, are some reasons you may find it necessary or desirable to reconfigure the user library.
The package specification v_usr_conf.1.ada defines and describes the components that you can modify to provide the Apex run-time environment for your application program. Do not modify this file.
To configure the user library, modify the default version of the body of the package, v_usr_conf.2.ada.
The file v_usr_conf_i.1.ada (located in rational.ss) provides the data structures for the small block sizes, configuration tables and floating point control, constants which may be used to select configuration options, and routines for use within the configuration package.
- Configuring the User Library
- Configuration Parameters
- Configuring Ada.Real_Time
- Configuring Ada.Calendar
- Task Names
Configuring the User LibraryNote: The name of the configuration package must remain V_Usr_Conf.
Follow these steps to configure the user library.
- 1 . Copy the view from usr_conf.ss to your own subsystem:
GUI Commands
Visit $APEX_BASE/ada/usr_conf.ss
Highlight <UsrConfView>
Select File > Copy Object
Select the Views radio button.
Fill in <MySubSys> in the Destination field
Click OK.
Command Line
copy_view $APEX_BASE/ada/usr_conf.ss/<UsrConfView> <MySubSys>
- 2 . Edit the copied version of v_usr_conf.2.ada to provide the desired configuration parameters.
GUI Commands
Visit <MySubSys>/<UsrConfView>/v_usr_conf.2.ada
Click Edit
Make your changes
Click Save
Command Line
edit <MySubSys>/<UsrConfView>/v_usr_conf.2.ada
- 3 . Compile the files in the copied view.
GUI Commands
Visit <MySubSys>/<UsrConfView>
Select <Shift> Code or Select Code and then OK
Command Line
apex code <MySubSys>/<UsrConfView>
- 4 . Import the copied usr_conf view into the view where your application will be linked:
GUI Commands
Visit <MyApplicationView>
Click Control > Change View Properties
Add <MySubSys>/<UsrConfView> to list of Imports.
Verify that the Add/Replace button is selected.
Click OK
Command Line
apex import <MyApplicationView> <MySubSys>/<UsrConfView>
- 5 . Link your application. The configuration in your imported usr_conf view will be included instead of the default one provided in the archive library.
GUI Commands
Visit <MyApplicationView>
Highlight <My Application>
Select <Shift>Link or select Link and then OK.
Command Line
apex link <MyApplicationView>/<MyApplication>
Configuration ParametersThis section contains general descriptions and definitions of the user library configuration components.
The components and parameters vary depending on your system architecture and whether or not you are using a threaded version of Apex.
For the specifics of your release, consult the specification of package V_Usr_Conf contained in the file
$APEX_BASE/ada/usr_conf.ss/<UsrConfView>/v_usr_conf.1.ada
and modify the body, v_usr_conf.2.ada in the same view.
The configuration package parameters are grouped as follows:
- Memory Management
- Code Coverage
- Taskdeb Configuration Structure
- ADAPATH References
- Configuration_Table Structure
- V_Signal_Isr Routine
- V_Signal_Isr Routine
- V_Pending_Overflow_Callout Routine (For Non-Threaded Versions)
- Initialize/Finalize Routines
Memory Management
Note: The definitions in these tables are brief identifiers. See Memory Management for complete descriptions.
- Configuration_Table
- Mem_Alloc_Conf_Table Parameters Applicable To All Configurations
- Mem_Alloc_Conf_Table Parameters Applicable Only To Apex Managed Heap
- Storage Pool Configuration
- External Pool Callouts
- Multitask_Safe Malloc
- Kernel Pool Callouts
- Stack Configuration Parameters
Configuration_Table
Mem_Alloc_Conf_Table Parameters Applicable To All Configurations
Mem_Alloc_Conf_Table Parameters Applicable Only To Apex Managed Heap
Storage Pool Configuration
Storage Pool Configuration describes the routines to be used to create the runtime's standard storage pools.
External Pool Callouts
External Pool Callouts provide a mechanism for easily customizing the External_Pool's external interface.
Multitask_Safe Malloc
Multitask-Safe Malloc is an Apex provided implementation of malloc, free, and several other standard C heap management routines. It is in the alloc subdirectory of non-threaded usr_conf.ss views.
Kernel Pool Callouts
Kernel Pool Callouts provide a mechanism for customizing the Kernel_Pool's internal interface. These subprograms are called by the kernel when it needs to allocate/deallocate memory.
Stack Configuration Parameters
For applications that do not use tasking, managing stack usage is straightforward. The stack is simply the process stack.
For applications that use tasking, main task still uses the process stack, but each additional task gets a stack allocated from the heap.
Code Coverage
CCA Configuration Data
CCA Configuration Parameters
Note: The code coverage configuration parameters effect only programs collecting code coverage information.
Trace Configuration Data
Taskdeb Configuration Structure
The Taskdeb configuration record in the body of this package is initialized and it's address is stored in the Configuration_Table.
- Initialization Procedure Address
- Signal Number Configuration
- Trap Instruction Configuration
- Debug and Call Task Configuration
- Taskdeb Configuration Record
Note: For tasking programs with small memory configurations, you can store No_Addr and provide a null __TASKDEB_INITIALIZE routine.
Configuring Taskdeb has no hidden memory requirements for non-tasking programs.
To remove task level debugging from the configuration, assign Taskdeb_Config_Address to No_Addr and remove the taskdeb configuration record, that is, remove the section Taskdeb Configuration Structure from v_usr_conf.2.ada in your view.
Taskdeb Configuration Structure parameters are grouped into the following categories:
- Initialization Procedure Address
- Signal Number Configuration
- Trap Instruction Configuration
- Debug and Call Task Configuration
Initialization Procedure Address
Signal Number Configuration
Trap Instruction Configuration
Note: UNIX-based self debuggers start the target program with Self_Signal.
Cross debuggers do not. The target program must be started by a trap instruction inserted at the next instruction executed.
Debug and Call Task Configuration
Taskdeb Configuration Record
Taskdeb_Config_Address is the address of the Taskdeb configuration record.
ADAPATH References
Referencing the external symbol __ADAPATH_ includes a number of extra variables (about 16 addresses) and extra symbols with the names __ADAPATH_.... in the Ada executable. These symbols determine the directories that contain the runtime system libraries.
These variables are used for debugging in the development process. This section may be removed in user configurations to save a few bytes of memory in each ada executable.
Configuration_Table Structure
Modify the constant Configuration_Table in the body of this package to describe your user program environment to Apex.
This record is passed to Ts_Initialize during user program startup to control initialization. The declaration of the record's type is in package V_Usr_Conf_I.
Each parameter is described in detail. The parameters are grouped into the following categories:
- Exception_Unwind_Safe package
- Floating Point Coprocessor Configuration Parameters
- Multithreaded Ada Configuration Parameters
- UNIX Signal Configuration Parameters
- Time Slice Configuration Parameters (For Non-Threaded Versions)
- Attributes Configuration Parameters
- Miscellaneous Configuration Parameters
Exception_Unwind_Safe package
This package is used to call initialization procedures and tables of procedures, that is, the elaboration table.
Floating Point Coprocessor Configuration Parameters
For information about floating point coprocessor control registers, see the documentation for your coprocessor.
Multithreaded Ada Configuration Parameters
Note: For a description of Apex support for Multithreaded Ada, threads, and POSIX threaded runtimes, see the Using Multithreaded Ada.
UNIX Signal Configuration Parameters
Time Slice Configuration Parameters (For Non-Threaded Versions)
Attributes Configuration Parameters
Miscellaneous Configuration Parameters
V_Signal_Isr Routine
The compiler emits code to call this routine for an interrupt entry in an active task. The interrupt entry acts as a signal that is posted when the interrupt occurs.
The starting address of Interrupt_Entry_Isr is passed to the Attach_Isr kernel service to install the ISR for the interrupt entry. When the interrupt occurs:
<<Interrupt_Entry_Isr>> MOV i, $arg0_reg -- address of interrupt entry's -- ISR header record
is executed which in turn calls this routine.
Additionally, the compiler emits code to call the Create_Signal kernel service to create a signal associated with the entry. This signal is posted by this routine.
This routine is called for all active task interrupt entry ISR's.
The body for this routine can be modified to do user specific processing before posting the interrupt entry's signal.
V_Pending_Overflow_Callout Routine (For Non-Threaded Versions)
Routine called when an ISR (signal handler) calls a kernel service and the queue of pending requests is full.
The default action for a pending kernel service request queue overflow is to print a diagnostic message and then exit.
Initialize/Finalize RoutinesV_Start_Program
is the default entry point into the Ada program.
V_Start_Program_Self
is called from the operating system environment on a native system in the standard manner. On UNIX, for example, this is with parameters argc, argv, envp.
V_Start Program_Common
Completes the preliminary program initialization and calls Ts_Initialize.
Ts_Initialize
The address of V_Start_Program_Continue is passed as a parameter to Ts_Initialize. When Ts_Initialize completes its tasking initialization, it calls V_Start_Program_Continue.
V_Start_Program_Continue
V_Start_Program_Continue does any further initialization and does the program elaboration by executing each procedure in the elaboration table.
V_Integrated_Init
May be called during the initialization/elaboration of the foreign language portion of the program that is tightly integrated with Ada. This routine will do the initialization required to share memory management and exception unwinding with the foreign language. If the foreign language is provided by a vendor other than Rational, this routine will not be called.
V_Adainit
Initializes and elaborates the Ada portion of a program.
V_Adafinal
Finalizes the Ada portion of a program.
Configuring Ada.Real_TimeAnnex D of the Ada Language Reference Manual (LRM) defines the Ada.Real_Time package to provide a standard interface to real time services (LRM D.8). In particular, the Time type represents real time with a precision defined by the Time_Unit constant, and the Clock function returns the current time, updated at intervals specified by the Tick constant. Values of the Time type can also be used in delay until clauses, suspending tasks until the specified real time has arrived.
Ultimately, the Clock function and delay clauses must be implemented by the Ada runtime using the underlying hardware. The support provided by the hardware will vary in the granularity and range of the hardware clock, the intervals at which delays can be checked, and the degree to which these features can be configured by programming the hardware. One way of accommodating these differences would be for the Apex to use a uniform implementation of the Time type across all platforms and translate between this and the hardware time representation used by the underlying clock and delay facilities. However, it is more useful for the Ada.Real_Time package to reflect the hardware as closely as possible. This can increase the efficiency and accuracy of translations between the Ada and hardware representations of time and provides Ada applications with information about the underlying support for time.
The Apex implementation of the Time type is a compromise between these two extremes. For all versions of Apex, the Time type is a 64 bit signed integer count of Time_Unit intervals from a fixed epoch (note that Time_Span has the same representation but is interpreted as an interval).
While the format of Time as a 64 bit integer is fixed, Time_Unit itself is not, and is configured to reflect the hardware representation of time. For example, if the clock is implemented by a hardware register that is incremented at a fixed interval, e.g. the Time Base (TB) register of PowerPC processors, then the Time_Unit is most naturally defined to be equal to this interval. The value of Tick is also configured to reflect the rate at which the clock hardware is updated. In some cases the underlying time base may not have sufficient resolution for Time_Unit, which must be no greater than 20 microseconds; in such cases the time base should be evenly divisible by Time_Unit to avoid roundoff errors.
The epoch will vary from platform to platform, and Ada.Real_Time provides no way to associate a Time value with an external date and time. This service is provided by the Ada.Calendar package which defines its own Time type and Clock function. While the LRM does not define a relationship between Ada.Calendar.Time and Ada.Real_Time.Time, in Apex these two types have identical representations, and the two Clock functions share the same underlying implementation.
Time Configuration Packages
This section describes the various packages that allow the behavior of Ada.Real_Time to be configured. Following sections document how these general descriptions apply to specific Apex products.
Ada.Real_Time
The Ada.Real_Time package itself is provided as modifiable source in Apex Embedded for Rational Exec and for Tornado. However, the only definitions that need to be configured to match the underlying support for time are Time_Unit and Tick, and these are derived from the Apex_Real_Time_Conf package, described below. Ada.Real_Time itself should never need to be changed.
Real_Time
The Real_Time package in the usr_conf.ss subsystem is configurable in all Apex products. Do not confuse this with the Ada.Real_Time package in real_time_systems.ss. Ada.Real_Time presents the interface defined in Annex D of the Ada LRM; Real_Time package provides the runtime implementation of much of Ada.Real_Time, in particular time arithmetic and conversions between one representation of time and another, as between Time_Span and Duration values. The version provided by Rational will always work, but the operations may be more general than desired; it may be possible to simplify some of the arithmetic using board-specific information. For example, if:
Time_Unit = Duration'Small
that is, if the representation of Duration is the same as that of Time_Span, it would be advantageous to replace the arithmetic in Real_Time.To_Duration and Real_Time.To_Time_Span with unchecked conversion.
Apex_Real_Time_Conf
The Apex_Real_Time_Conf package in real_time_systems.ss defines the relationship between the Ada representation of time and that supported by the hardware. It is present, but not necessarily configurable, in all Apex products. When configurable, Apex_Real_Time_Conf provides the simplest and most direct means of time configuration, and modifying it has a consistent effect on the other time-related packages. Of course, the hardware will not always be able to support a particular configuration of Apex_Real_Time_Conf. Even when it can, the software drivers may not take advantage of all of the features of the hardware. In such cases, the configuration should be rejected by terminating the program. All definitions in Apex_Real_Time_Conf are static constants of universal numeric types. (Except Hardware_Ticks_Per_Ada_Tick, which is an integer variable on POSIX based platforms). This is necessary in the case of Time_Unit, which is defined in Annex D as a universal real constant:
Time_Unit: constant := implementation-defined-real-number;
Other values are kept as universal constants to avoid roundoff errors until they are used by the runtime system.
There are at least six such constants for all Apex platforms (see Table 10). These constants are often redundant. For example, in configurations provided by Rational, Hardware_Ticks_Per_Ada_Tick is either 1, meaning that the Clock function accesses the hardware time base directly, or the same as Hardware_Ticks_Per_Delay_Interrupt, meaning that the runtime updates current time when it checks for pending delay clauses. This will probably be true of all platforms, but two separate definitions clarifies the configuration model.
Other constants besides these six are allowed, usually representing aspects of the hardware from which the six required constants are derived. For example, PowerPC platforms use the Time Base (TB) register of the CPU to implement the clock. This register is incremented once for every four bus clock cycles. Rather than defining the hardware tick value directly, it is clearer if its relationship to the CPU bus clock is made explicit. For example, if the processor bus frequency is 66 MHz, Time_Unit and the hardware tick value can be calculated as:
Bus_Clocks_Per_Second : constant := 66_000_000.0; Hardware_Ticks_Per_Second : constant := Bus_Clocks_Per_Second / 4.0; Time_Units_Per_Hardware_Tick : constant := 1; Time_Unit : constant := 1.0 / (Time_Units_Per_Hardware_Tick * Hardware_Ticks_Per_Second);One common motivation for modifying Apex_Real_Time_Conf is to increase the resolution of the Time type by decreasing the value of Time_Unit. Since Time_Units_Per_Hardware_Tick is dependent on the value of Time_Unit, changing just the latter would also reconfigure the underlying hardware time base. To change the resolution of Time without affecting the hardware configuration, both of these constants must be changed together such that
Time_Unit * Time_Units_Per_Hardware_Tick
remains constant. It is generally best to make Time_Units_Per_Hardware_Tick a power of two as noted in Table 10.
An example of a case where Time has greater resolution than the underlying time base is the default Tornado configuration. It defines the hardware time base (Tornado tick) to be 1/60 second. This is too small for the LRM definition of Time_Unit, which specifies a maximum of 20 microseconds, so Time_Units_Per_Hardware_Tick is defined to be 1024, the smallest power of two that satisfies this requirement. Time_Unit is therefore 1.0/(1024.0*60.0) seconds, or about 16.3 microseconds.
V_Krn_Conf.V_Timer_Support
The V_Krn_Conf.V_Timer_Support is only provided with Apex Embedded for Rational Exec and Tornado; it is always configurable. It provides an interface to the underlying hardware time facilities, but is very different in these two embedded products, as described below.
POSIX Time Configuration
Most aspects of Ada.Real_Time are fixed for POSIX based Apex products, including all native Apex products and Apex Embedded for LynxOS. These operating systems provide the POSIX representation of time as an integer count of seconds and nanoseconds. Since the Apex runtime has no direct access to the hardware, it reflects the POSIX representation in this fixed configuration, defining Time_Unit as 1 nanosecond; the Time type is therefore a 64 bit count of nanoseconds from the epoch. Ada.Real_Time.Tick is similarly derived from the POSIX operation clock_getres(), which provides the rate at which the POSIX clock (as reported by clock_gettime()) changes.
The Apex_Real_Time_Conf package is provided with these products, but the real_time_systems.ss subsystem is a nonconfigurable API. There is no V_Krn_Conf package.
The Real_Time in usr_conf.ss is configurable, though since the representation of the Time type is fixed there is less motivation for configuring arithmetic and conversion operators for it. If you modify Real_Time, the instructions for using the modified package are essentially the same as that for the Calendar_Configuration package described below, also in usr_conf.ss:
- 1 . Follow steps 1-2 in Configuring the User Library for creating a new usr_conf.ss view.
- 2 . Edit the context clause of v_usr_conf.2.ada in this new view to add:
with Real_Time;
- 3 . Modify Real_Time in the new usr_conf.ss view
- 4 . Proceed with steps 3-5 in Configuring the User Library.
Time Configuration for Apex Embedded Platforms
Apex Embedded (except for LynxOS) provides the Apex_Real_Time_Conf, Real_Time, Ada.Real_Time, and V_Krn_Conf.V_Timer_Support packages in source form, so the representation of time and time related behavior can be configured by modifying any or all of these packages. Changes to these configuration files may require recoding one or more of the real_time_systems.ss, usr_conf.ss, and krn_conf.ss views; if in doubt about dependencies it is safest to recode all of them before linking an application.
V_Krn_Conf is part of the kernel configuration built in the krn_conf.ss subsystem. Modifying this package and making the changes available to application programs is covered in the appropriate configuration guides for the Rational Exec microkernel and Tornado products.
Object code resulting from the compilation of the Real_Time package is included in the link closure of application programs as specified by the Link.des file in the usr_conf.ss subsystem. Changes to this package can therefore be incorporated by simply compiling the package and relinking the application.
Ada.Real_Time is imported into applications directly using with clauses; when such applications are relinked the Apex compiler will notice any changes and recompile the package.
Apex_Real_Time_Conf consists of compile-time constants, and as such generates no object code. However, it is on the closure of the remaining three packages, so changes to it should be treated as changes to all of them, requiring recompilation and relinking of the kernel, recompilation of Real_Time, and relinking of the application.
Time Configuration for Apex Embedded for Rational Exec
The Rational Exec product interfaces to the platform hardware through a Board Support Package (BSP). BSPs for a number of boards are available directly from Rational; others may be obtained from third parties, or you can write your own. These BSPs contain code that programs the hardware directly, without the mediation of an operating system or monitor.
The code that controls the timer hardware is in the BSP kernel configuration package V_Krn_Conf.V_Timer_Support, in the krn_conf.ss subsystem. This provides the most flexible configuration option; the drive code can be completely rewritten, even to support different timer hardware. By the same token, it is the most difficult, and requires a good working knowledge of the timer hardware. In any case, it should ensure compliance with the constants defined in the Apex_Real_Time_Conf package described above, otherwise the Ada Clock function, delay clauses, and time arithmetic will not reflect the behavior of the timer hardware. Further details on the configuration of V_Timer_Support can be found in "Timer Models for the Rational Exec Microkernel" in Chapter 2 of the Configuring Rational Exec Guide.
Time Configuration for Apex Embedded for Tornado
The Tornado OS provides software to control timer hardware and provides clock and alarm services. The Apex Embedded for Tornado runtime layers the implementation of the Time type, the Clock function, and delay clauses over this OS support. The function of the Apex time configuration in this case is largely to describe the Tornado OS support. In particular, the BSP and therefore configuration of the hardware drivers themselves is part of Tornado configuration.
Tornado represents time and duration as an integer count of ticks. The interval represented by a tick varies with BSP; the default value is typically 1/60 or 1/100 second. The Apex_Real_Time_Conf package must reflect the value of this tick, satisfying:
Time_Unit = 1.0/(Time_Units_Per_Hardware_Tick * sysClkRateGet)
where sysClkRateGet is the Tornado function returning the number of ticks per second.
The typical default for the Tornado tick is too large to comply with the Ada definition of Ada.Real_Time.Tick, which must be a millisecond or less, or of Ada.Real_Time.Time_Unit, which must be 20 microseconds or less. Time_Unit can be brought into compliance by defining Time_Units_Per_Hardware_Tick large enough, but Tick is a measure of how often the clock changes, and so must be identical with the Tornado tick interval.
Tornado does allow the system tick to be adjusted using the sysClkRateSet() function. However, the default runtime configuration does not attempt to do this, since the tick is a system global, and Apex applications may not be the only ones that depend on it. Instead, the Apex_Real_Time_Conf configuration file is checked for compatibility with the Tornado system tick during runtime initialization, in Real_Time.Real_Time_Init. If this check fails, the runtime prints a message and terminates the program, e.g.:
This BSP is configured for a VxWorks tick of 100. The VxWorks sysClkRateGet() function returns 60. Try reconfiguring real_time.ss//apex_real_time_conf.1.ada such that 1.0 / (Time_Unit * Time_Units_Per_Hardware_Tick) is equal to the VxWorks tick. In most cases, this can be done with: Hardware_Ticks_Per_Second : constant := 60; It is possible to modify Real_Time_Init to call sysClkRateSet() to force the Tornado tick to comply automatically; see comments in the source code for more details.
Both the Ada Clock function and delay clauses are implemented using Tornado services. The Tornado tick interval defines the granularity of all of these services, so the only supported value for Hardware_Ticks_Per_Delay_Interrupt and Hardware_Ticks_Per_Ada_Tick are therefore both 1. The default Real_Time_Init checks these values as well, printing out error messages and terminating the application for other values:
Hardware_Ticks_Per_Delay_Interrupt: unsupported value Hardware_Ticks_Per_Ada_Tick: unsupported value
As with Rational Exec, the Apex Embedded for Tornado defines a V_Krn_Conf.V_Timer_Support package in the krn_conf.ss subsystem. Unlike Rational Exec, the subprograms in this package do no interface to the hardware but instead provide for translation between Ada Time and duration types and VxWorks tick counts. The Ada kernel layer of the Apex runtime archive library implements Ada time services by accessing the Tornado operations directly, but these operations need time in VxWorks ticks. The Ada kernel is precompiled and cannot use the constants in Apex_Real_Time_Conf directly, so V_Timer_Support provides translation between Ada Time_Span and Duration types and ticks for this purpose. In general, the only reason to configure this package would be to optimize the translation arithmetic based on special knowledge of the relationship between Ada and Tornado time representations. For example, if one is a power of two multiple of the other, multiplication and division can be replaced by shift operations. Note that this particular optimization is provided by the default configuration for Time_Span translation based on the values of the Use_Log_Time_Units_Per_Hardware_Tick and Log_Time_Units_Per_Hardware_Tick constants described above.
Configuring Ada.CalendarAda.Calendar is a standard package defined in LRM 9.6. It defines a Time type, a Clock function returning the current time as a value of this type, a set of subprograms relating Time values to times and dates appropriate to an implementation-defined time zone, and arithmetic operations on Time.
The Apex runtime provides default implementations of the Time interpretation subprograms that will work for many applications. In the case of native runtimes for POSIX operating systems, the default implementation uses operations provided by the OS for date and time interpretation (localtime_r() and mktime()). This allows adjustment of time interpretation, in particular the time zone, using the TZ environment variable. The default implementation also initializes the clock internal to the Apex runtime using the OS clock service. This is also the default implementation provided with Apex Embedded for LynxOS and Apex Embedded for Tornado, both of which provide the required operations.
The Apex Exec cross-compilation systems for embedded platforms provides a different default implementation since there is no underlying OS to provide the current time or interpret time and dates. The default implementation for Ada.Calendar initializes the runtime clock to an arbitrary start date and provides and interprets time as Greenwich Meridian Time (GMT) with no Daylight Savings Time (DST) correction.
Those using Apex to program Embedded platforms will often find the interpretations provided by the default Ada.Calendar implementation inadequate for their purposes, if only because the time zone or daylight savings time convention is incorrect for their location. Those using Apex to create native applications will usually find the default adequate, though there are occasions where special interpretations may be useful. For example, one solution proposed for two-digit year (Y2K) problems is to set the date back 28 years (since the correspondence between days of the week and dates from 1901 to 2099 repeat at that interval) and then adjust the resulting output in a post-processing step. Ada.Calendar can be adjusted to perform this conversion by subtracting 28 from year numbers in Split and adding 28 to year numbers in Time_Of.
The Calendar_Configuration Package
To allow for configuration of Ada.Calendar, the source code for the time interpretation subprograms is exposed in the Calendar_Configuration package, located in the usr_conf.ss subsystem together with the general V_Usr_Conf runtime configuration package. Calendar_Configuration exports time interpretation subprograms which are in turn imported by Ada.Calendar to implement those defined by the LRM. Modifying or replacing these routines will change the behavior of the corresponding Ada.Calendar operations.
Most of the exported subprograms are identical to those in Ada.Calendar:
function Year (Date : Time) return Year_Number; function Month (Date : Time) return Month_Number; function Day (Date : Time) return Day_Number; function Seconds (Date : Time) return Day_Duration; procedure Split (Date : in Time; Year : out Year_Number; Month : out Month_Number; Day : out Day_Number; Seconds : out Day_Duration); function Time_Of (Year : Year_Number; Month : Month_Number; Day : Day_Number; Seconds : Day_Duration) return Time;
The corresponding exported names are uniformly modified to ensure uniqueness during the link:
pragma Export (Ada, Year, "__CALENDAR_YEAR"); pragma Export (Ada, Month, "__CALENDAR_MONTH"); pragma Export (Ada, Day, "__CALENDAR_DAY"); pragma Export (Ada, Seconds, "__CALENDAR_SECONDS"); pragma Export (Ada, Split, "__CALENDAR_SPLIT"); pragma Export (Ada, Time_Of, "__CALENDAR_TIME_OF");
The Calendar_Configuration package is not part of the applications closure but is instead linked in directly, so no elaboration is performed. To allow for any required initialization, the runtime calls an initialization procedure in Calendar_Configuration during application startup. This is especially useful for setting the Ada runtime clock with the current time:
procedure Initialize; pragma Export (Ada, Initialize, "__CALENDAR_INITIALIZE");
These subprogram declarations and the corresponding exported link names should not be modified.
Modifying Calendar_Configuration
It should generally be sufficient to modify the body of Calendar_Configuration, calendar_configuration.2.ada. The most common modifications will be to Apex Embedded for Rational Exec products, to configure the time zone and (optionally) set the current time from a hardware Real Time Clock (RTC).
At the beginning of the embedded version of calendar_configuration.2.ada there are declarations specifying the time zone and daylight savings time conventions; comments provide instructions for changing these to match your location.
If your hardware provides an RTC, you can use this to set the clock in the runtime from the Initialize procedure. How this is done will depend on the format in which the clock hardware provides the time and date. In general, it will have to be converted into time and date values that can be passed into the Time_Of function to convert it to the corresponding Time value. V_I_Time.Set_Time (in the rational.ss subsystem) can then be used to set the runtime clock. Note that V_I_Time.Set_Time takes an argument of type V_I_Types.Time_T, the underlying runtime time type. The Time value returned by Time_Of can be converted to Time_T using the To_Time function provided in the body of Calendar_Configuration.
The default implementation of Calendar_Configuration.Initialize provided with Apex Embedded for Tornado products sets the Ada clock from the Tornado system clock as reported by the POSIX function clock_gettime(). This in turn depends on the Tornado clock being set correctly before the Apex application is started. Tornado doesn't always do this automatically, frequently resulting in a system time, and therefore an Ada time, of the POSIX epoch (January 1, 1970). If Tornado can't be configured to set the system time automatically, it should be possible to use a separate application to set it using the POSIX clock_settime() function.
For other modifications, and for modification of the Calendar_Configuration package shipped with Apex native systems, the only general guidelines are to adhere to the parameter profiles of the subprograms exported in the package spec.
Using a Modified Calendar_Configuration Package
As with the V_Usr_Conf package, the default version of Calendar_Configuration is included in the runtime library archives linked with each application. To replace it with a modified version, follow these steps:
- 1 . Follow steps 1-2 in Configuring the User Library for creating a new usr_conf.ss view.
- 2 . Edit the context clause of v_usr_conf.2.ada in this new view to add:
with Calendar_Configuration;
- 3 . Modify Calendar_Configuration in the new usr_conf.ss view
- 4 . Proceed with steps 3-5 in Configuring the User Library
The modified Calendar_Configuration will be included instead of the default one in the archive library. Note that V_Usr_Conf will also be replaced; it is not possible to replace only Calendar_Configuration. However, an unmodified V_Usr_Conf is just the source code for the default version and so will not change any of the default configuration.
Task NamesThe runtime assigns a unique name to each Ada task. Part of this name is a pseudorandom identifier based on the source code used to specify the task. The function used to generate this pseudorandom identifier is declared in usr_conf.ss views and can be configured. For more information see Task Names.
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |