| |
|
|
|
|
|
Rational Apex Embedded Solaris to RH-32 Release Note for Rational Exec This release note applies to Release 4.0.0 B of Rational Apex Embedded Ada 95/83, Solaris to RH32 for Rational Exec. It provides a development and runtime environment for real-time embedded applications.
Note: Starting with the 4.0.0 releases, the rada executable used to code Apex Embedded Ada views is the same executable shipped with the native product (Please check the native Apex patch descriptions for possible newer versions of rada).
Note: To ensure proper operation of the Generic_Elementary_Functions implementation in the Ada95 Numerics Annex, the native compiler for Sun Solaris should be at patch level 200109271-1 or higher.
Latest Release NoteThe latest Release Notes for Rational Exec can be viewed on–line by selecting Help > Manuals > Rational Apex Embedded Manuals....
The Rational Apex Embedded for Rational Exec product includes a Statistical Profiler, Format Converter, and a Instruction Set Simulator. The Tasking Logic Analyzer, Network TDM (EneT), No-Kernel Configuration, and Mark Kernel configuration are not supported in this release. In addition, there is no C/C++ compiler, nor is the built-in assembler support implemented for the RH32.
Full instructions for using this product are provided in Programming for Rational Exec. Configuration information is provided in the Configuring Rational Exec.
For users who may be migrating from VADS to Apex, additional information about porting application software is provided.
This document contains only release notes specific to the Rational Exec aspects of this product. Release notes for the parts of this product also applicable to the native Apex product are provided in a separate release note document.
This document covers the following:
- Host and Target Specifications
- Documentation
- New Features in Release 4.0.0B
- Known Limitations
- Defects Resolved
Host and Target SpecificationsHost: Sun SPARC workstation running Solaris 2.6, Solaris 7, or Solaris 8.
Target: Honeywell RH32 CPU.
DocumentationDocuments specific to this product are:
Release Notes for Rational Exec (this document)
Programming for Rational Exec
Configuring Rational Exec
Command Reference
Utilities GuideThese documents are available in both hard-copy and online format. Online they can be accessed through the Help > Manuals command or the Doc List button in the navigation bar of each online manual page.
New Features in Release 4.0.0BApex GUI and Command Line Features
Single Rada and apex_compiler_tool
Starting with the 4.0.0 releases, the rada executable used to code Apex Embedded Ada views is the same executable shipped with the native product (Please check the native Apex patch descriptions for possible newer versions of rada). The code generator apex_ada_cg_phase and optimizer apex_ada_optim_phase executables are not shared. The location of the rada, apex_ada_cg_phase and apex_ada_optim_phase executables are determined from the view the user is coding in. The apex_compiler_tool script can be used to determine the location of these tools. For example:
Model Description Files
Apex Embedded provides many $APEX_BASE/ada/model.ss views with each release. The view names can be long and their meaning can be obscure. To help make sense of the information encoded in the view name, each model is now shipped with a description file. The description files explain what the cryptic portions of the view name mean.
This description can be viewed from the command line by invoking the properties command with the -model_info option. The properties command can specify a model.ss view directly, or another view modeled on a model.ss view.
The description can also be viewed from the GUI. Dialogs that ask the user to select a model (e.g. File > New > New View) have a navigation icon next to the text field. Clicking the navigation icon displays the Model Navigator dialog. Once a specific model has been selected within the Model Navigator dialog, the model description file will be displayed in the "Information on selected model" section.
Model Visibility
When a user creates a new BSP (via the File > New > New BSP dialog or the apex_new_bsp command), they create new model.ss views. If the new model.ss views are located in the original $APEX_BASE/ada/model.ss subsystem, they will be visible to all users via the Model Navigator dialog.
However, if the new BSP has a destination base other than $APEX_BASE, the user must specify the level of "visibility" the new model.ss views should have: Everybody, Just Me, and Nobody.
The level of visibility effects which users see the models via the Model Navigator dialog. It does not effect any users ability to use the new views.
This visibility is achieved through the use of Apex Project files. Models with a visibility of Everybody will be visible to all users after they activate the user_models.everyone project. Models with a visibility of Just Me will be visible to the BSP creator after he/she activates the user_models.just_me project. Details on project activation can be found in the documentation for File > New > New BSP or apex_new_bsp.
Run, Debug, Download, and Targets Dialogs
The following four dialogs have been combined into a single dialog.
- File > Run
- File > Debug
- File > Download
- Tools > Targets
Each function is still accessed via the menus above. Once the dialog appears, users can switch between the four functions by selecting tabs within the dialog.
Upgrade Release
The Control > Maintenance > Upgrade To New Release dialog and corresponding apex_upgrade script are part of the Apex Native product. Starting with the 4.0.0B Native Apex release, this dialog and script now work for Apex Embedded.
ClearCase Integration
Users can now link, run, and debug programs from within Clearcase. Also, if you are in a clearcase view when starting your apex session, the File > New > BSP dialog will give you the option of creating the new BSP as Clearcase *.rss subsystems rather than CMVC *.ss/*.{wrk,rel} views.
New Source Release and apex_create_runtimes
Customers can purchase source releases of Apex Embedded products. These source releases include full source to $APEX_BASE/ada/*.ss/*.rel views (no API's) including the views used to create the runtime archives.
The File > New > New Source Release dialog can be used to make a copy of the entire set of views so that development work will not alter the installed product.
When doing development that effects the runtime archives, it can be difficult to determine what views need recoding, and what runtimes need re-linking after source code changes have been made. To simplify this process, we have created the apex_create_libraries command. The syntax of this command is simple. You point it at the directory containing links to all the runtimes archives (i.e. the directory identified by a BSP model's RUNTIMES switch) and it takes care of coding views, and re-linking archives.
Ada Compilation System
Alignment of Types and Objects
The default alignment of types and objects has changed in Apex 4.0.0. Be aware that in the absence of representation clauses specifying the alignment of a type or object, the compiler is free to choose the optimal alignment with respect to performance. See the Apex native Release Notes for more details.
Support for implementing new I/O channels for Ada.Text_Io
Support for implementing different I/O channels other than the default is provided in Rational Apex 4.0.0 Embedded. The new design allows for either replacing the default or simultaneously having multiple I/O implementations for Ada.Text_Io.
Runtime
Kernel Configuration
A new tool has been added for configuring the Rational Exec kernel to remove unneeded services so as to reduce its size. For details, see the section titled "Configuring the Kernel Services Package" in Configuring Rational Exec.
Time Configuration
The configuration of the Ada.Real_Time.Time type, including the value of Ada.Real_Time.Time_Unit, Ada.Real_Time.Tick, their relationship to the underlying hardware time base, and the granularity of delay clauses, has been streamlined in Rational Apex 4.0.0 Embedded. See Using the Ada Runtime for details.
Note that Time cannot be configured in Apex Embedded for LynxOS, nor for any self-hosted version of Apex.
Task Names
In Rational Apex 4.0.0, task names based on the source code are available at execution time. These names can be obtained using the Ada.Task_Identification.Image interface (see LRM C.7.1) from the systems_programming.ss subsystem. Note that these are not fully qualified names, and that generic names are used for anonymous tasks (e.g. task array elements). The image of a task sequence number is included in these names to insure that they will be unique within a given program execution.
New Features in Release 3.2.0BAda Compiler
Apex 3.0.1 for embedded platforms included the package Language in the rational.ss subsystem. This package provides constants useful for interfacing to other language implementations on those platforms. For example, the prefix character added to link names by those language implementations.
The function of this package has been superseded by the Apex implementation of the Import, Export, Convention, and Calling_Convention pragmas. In particular, the compiler will treat the External_Name argument to the Import and Export pragmas as a name in the target language and perform the necessary modifications to that name to create the corresponding link name. Note that no modifications are made if the Link_Name parameter is used instead of External_Name.
These features make the Language package obsolete for the Apex embedded products. It has therefore been removed from 3.2.0 and later embedded releases.
Address Clauses
In embedded VADS programs Ada address clauses for with static addresses were represented by a linker group to prevent overlapping use of the memory associated with address clause variables. This feature is no longer supported by the Apex compiler. The Apex compiler allocates a pointer to the address specified in the address clause and all accesses to the variable are implemented as indirect references through this pointer.
In some circumstances the optimizer is able to optimize away the pointer and make references directly to the specified address. There is no mechanism to assure that the specified memory address isn't allocated by the linker to some other part of the user program.
Command-line Interface
For a complete description of the following commands see the Programmer's Guide.
New commands
Changed commands
The new version of apex_execute differs as follows:
- It has a -help option.
- It can take a -logical_target parameter (though if this parameter is not specified, the LOGICAL_TARGET_NAME switch for the enclosing view).
- It is written in apex shell, not cshell.
The new version of apex_simulator differs as follows:
- has a -help option.
- is written in apex shell, not cshell.
- has a -sim_file option which allows you to override the default selection.
- has a -logical option which allows you to map the simulator to a logical target as part of the apex_simulator command.
Removed commands
apex_add_target and apex_target_control have been replaced with the new commands mentioned above.
Debugger
Attaching task entries to interrupts has been made operational on all architectures.
Documentation
There is a new section in the Configuration Guide on Running an Application without TDM.
GUI
Tools > Convert from the GUI now successfully creates a message in the directory window to reflect the update.
Runtime
All of the runtime archive and predefined components have been compiled at optimization level 2 with the optimization objective set to space (instead of time). This provides the smallest footprint for embedded applications as well as the best performance.
Target Control
Target Control has been restructured for the 3.2.0B release. New target control GUI implementation allows physical targets to be globally visible resources for a development team yet still allow individuals to reserve individual physical targets. Multiple targets can be manipulated from the same Apex session.
Please read the Target Control Chapter in the Programming Guide and refer to Getting Started.
Validation Testing
ACVC validation test suites are certified at optimization levels 0, 1 and 2 with optimization objective of SPACE.
New Features in Release 3.0.2This release is not available for all platforms. It is essentially the 3.0.1 release with all patches applied. In addition, there are a number of bug fixes, in particular, those found in the code generator. See also Known Limitations.
New Features in Release 3.0.1New BSPs
In this release, the mvme2603, mvme2604, and mvme2700 are supported by BSPs with the board_variant identifier mvme2xxx.
The mvme1603 and mvme1604 are supported by BSPs with the board_variant mvme160x.
Support has been added for the mpc860 board identified with board_variant mpc860ads.
For information about the term board_variant and BSP naming conventions, See "View Naming Conventions" in the Configuring Rational Exec.
Debugger
Multiple Target Extensions
Users can now debug multiple targets using only one debugger engine. For multiple target debugging, users must use the program_file debugger invocation option and specify the information for each target that will be in the debug session.
Additional information on multiprogram debugging can be found in Using the Apex Debugger and Programming for Rational Exec.
Additional support is provided for target systems that support hardware or software synchronization between the targets in the system. This synchronization is characterized by one-stop/all-stop and one-go/all-go target activity and requires TDM support. Debugger support of synchronized target hardware is described in Programming for Rational Exec.
Minimal Disturbance Debugging
This Apex debugger feature enables users to debug one or more embedded targets with minimal disturbance. The debugger is asynchronous, allowing the user to debug the application while it is running. This feature is only available on Sun Solaris => PowerPC systems.
Two new environment variables, APEX_RDT_SERVICE and APEX_RDT_TIME are required for this feature to work.
Minimal disturbance debugging is enabled using the Realtime checkbox on the File:Run or File > Debug dialog, or the –realtime, –realtime_attach, or –realtime_attach_with_exceptions command line options to the apex_debug command.
Minimal disturbance debugging is described in detail in "Minimal Disturbance Debugging" in Programming for Rational Exec.
Inlining of Machine Code
In Apex 2.4.2, the compiler front-end had difficulty expanding machine code procedures inline, and in particular, handling <parameter_register>'Ref operands. The workaround was to refer to out-of-line machine code procedures and to avoid auto-inlining by not using Optimization Level 2.
In Apex 3.0.0, most problems with inlining machine code procedures have been fixed. Some problems remain. For example, there are problems in expanding <register'Ref> references when parameter registers are referenced inside of implicit functions. As discussed above, auto-inlining of machine code procedures is now disabled at all levels of optimization.
If you choose to implement a machine code procedure so that it is inlined, take special care if that function uses the disp() or base() implicit functions. These functions will not be expanded properly if a parameter register is referenced with a 'Ref inside of the call to base() or disp(). For example:
procedure B_Srl (L, Cnt : Integer; X: out Integer) is use Machine_Code; begin Code_2'(Move, X'Ref, L'Ref); Code_2'(Shr, X'Ref, Base (Cnt'Ref)); -- *** Cnt'ref won't work here end B_Srl; pragma Inline_Only (B_Srl);
The problem is that, above the Cnt'Ref construct refers to the parameter register Cnt, and this reference occurs inside of a call to the intrinsic function base() (which generates a register indirect reference). The base() reference will not expand correctly; in fact, it will expand into a reference to R0 (register zero).
procedure B_Srl (L, Cnt: Integer; X : out Integer) is use Machine_Code; begin Code_2'(Move, X'Ref, L'Ref); Code_2'(Move, T0, Cnt'Ref); Code_2'(Shr, X'Ref, Base (T0)); end B_Srl; pragma Inline_Only (B_Srl);
The workaround, shown above, is to move the parameter register (Cnt) into a physical machine register (T0), which is used as a temporary.
Safe To Use the V_BITS Interface
Because of the fixes in the implementation of the inlining of machine_code procedures, it should now be safe to use the V_BITS package exported by the vads.ss subsystem. The V_BITS package exports bit operations that are implemented as inline expansions and are likely to be more efficient than the non-inline implementation in V_I_BITS. The V_I_BITS function was recommended for use in 2.4.2 due to the bug in the implementation of inlining.
Reference to Large Unsigned Constants
In machine code procedures, it is sometimes necessary to refer to a large unsigned constant, which has bit 31 set (the sign bit in a signed 32 bit integer). In Apex 2.4.2, such references were allowed. However, in Apex 3.0.0 and above, these constants are checked more carefully to ensure that they conform to the proper type semantics. If a reference to a constant has the sign bit set, for example, to 16#8000_0000#, the number must be passed as an argument to the built-in intrinsic function, IMMED_MOD32(). For example,
TestMate Operability with Apex RH32 Embedded
All features of TestMate Embedded are compatible with this version of Apex RH32 Cross with the exception of the TestMate trap based coverage analyzer. The RH32 support required by the TestMate trap based coverage analyzer has not been fully implemented; thus the trap based coverage analyzer will not properly function. If language specific tests are to be used (Ada test cases), then the driver/script generation feature of TestMate requires that the trap based coverage analyzer harness exist in order for the script link to succeed. Therefore, it is still required to build (see TestMate's tmbuild command) the required set of TestMate views as well as the trap based coverage analyzer harness archive library, even though the activation of the trap based coverage analyzer will result in program failure. The source instrumented coverage analyzer, however, can be used to gather coverage.
New in Release 3.0.0Configuration Pragmas
Apex 3.0.0 provides a new facility called "configuration pragmas," that provide a method for applying certain pragmas such as "pragma Suppress (All_Checks);" to all units compiled in a given view. The configuration pragma facility is defined in Appendix F (Ada83) and Annex M (Ada95) of the Compiler Reference manual. Briefly, when an Ada source file named pragma.1.ada is compiled in a given view, this "pragma" file specifies all the default pragmas that are to be applied to all units compiled in that view.
For example, the following pragma.1.ada definition:
- Suppresses all explicit checking, such as stack checks, overflow checks, range checks, and the like.
- For programs that do not use the abort statement, some additional extra checking code can be eliminated, with the "pragma Restrictions(...);" shown above.
Note: The contents of a pragma.1.ada unit is only a list of pragmas. There is no containing package specification, or other syntax to introduce the pragmas.
See Configuration Pragmas for Apex 3.0.0, 3.0.1 and 3.0.2 under Known Limitations.
Optimization Levels
The default optimization level is Level 1, which implies some optimization is done. You can change the default optimization by changing the OPTIMIZATION_LEVEL switch value. If this change is made in a model, the change will be apply for all views that use that model; therefore models can be used as a central place to change the default optimization level if required.
Optimization Level 1 is the default, because it provides a reasonable trade-off between compilation time, and the efficiency of the resulting generated object code. Optimization Level 2 will generally improve on Level 1, at some cost in compilation time.
"No optimization" is sometimes appropriate in code that has been tuned to meet certain hardware timing constraints, or in machine_code procedures that require explicit control over the instructions that are generated. Optimization Level 0 can be set as a compilation switch, and apply to all compilations in a view, or can be selectively enabled with:
This Optimize_Code() pragma must be located inside the procedure that it applies to.
In Apex 2.4.2, at Optimization Level 2, the compiler would sometimes aggressively "auto-inline" routines not already designated explicitly as inline routines. This could lead to certain difficulties, when the inlined routine was a machine code procedure. The Apex 3.0.0 compiler still performs auto-inlining at optimization level 2; the only difference is that it does not auto-inline machine coded routines. As discussed below, the OPTIMIZATION_OBJECTIVE:SPACE switch value can be used to decrease the degree of auto-inlining (of non-machine code procedures) at Optimization Level 2.
With Apex 3.0.0, it should now be safe to use Optimization Level 2 (because of problems with machine code, the recommended practice was to avoid Optimization Level 2 when compiling with Apex 2.4.2),
OPTIMIZATION_OBJECTIVE:SPACE
Apex 3.0.0 has improved the ability to minimize space when the SPACE optimization objective is asserted.
The switch OPTIMIZATION_OBJECTIVE:SPACE, turns off loop unrolling and makes inline expansion less aggressive. Only very small routines will be inlined... those for which the inlined body will be smaller than the call. For example:
Pragma Inline_Never
The pragma Inline_Never can be used to disable auto-inlining of a particular routine. However, in most cases this is unnecessary. OPTIMIZATION_OBJECTIVE:SPACE eliminates most of the auto-inlining situations. Further, Apex 3.0 will never auto-inline (choose to inline a routine that has no pragma inline, or pragma inline_only) a machine code procedure.
Control over Record Layout
A representation clause must be used to ensure that a record has a particular layout in memory. For example, this is necessary when Ada code calls a routine written in machine code and the called routine expects a specific layout. Without a representation clause, the Ada compiler is free to choose the ordering of fields inside a record, and often will reorder the fields, for example moving arrays to the end of the record, and scalars to the beginning of the record.
If the record of interest doesn't contain dynamic sized fields or discriminant-dependent fields, pragma Convention(c, ...) can be used to control the layout of a record to agree with the order of declaration of the fields inside the record. For example,
will control the layout of Record_Type to agree with the C language convention. Consult Annex M in the Apex Ada95 reference manual for details.
Kernel and TDM are Compiled and Built as Ada95 Views
The krn_conf.ss and tdm_conf.ss subsystems define views that contain Ada source code, which may be customized and extended to tailor the Ada runtime kernel and the Target Debug Monitor (TDM) to the user's specific requirements. In Apex 3.0.0 the kernel and TDM configuration views that are shipped with the product are defined as Ada95 views (in Apex 2.4.2 these views were defined as Ada83 views). Therefore, the user who is customizing the kernel and TDM should first become familiar with the differences between Ada95 and Ada83. A few important differences are discussed below.
- When compiling Ada95 code that makes use of the "for `Address use" clause, Apex 3.0.0 will generate a warning message of the following form:
To avoid default initialization apply a pragma Import to Thing
To avoid these warnings, and to avoid situations where the compiler generates initialization code, and that initialization code is unwanted, the source code should be modified to use the newer Ada95 "for thing'address use ..." syntax, and "pragma import(Ada, ..);" should be added. For example, the following Ada83 code:
(Consult Annex M of the Apex Ada95 Reference manual for details.)
The following table shows the difference between the value returned for 'Size, when compiled in an Ada83 view, and in an Ada95 view:
Ada95 defines 'Size as the smallest container that can contain the type's value, while Ada83 returns the size of the container allocated by default to hold values of the type. Code written for Ada83, and then ported to Ada95, that uses 'Size should be carefully checked to make sure that the code agrees with Ada 95's interpretation of 'size.
Note: The tdm_conf.ss and krn_conf.ss views must have the OPTIMIZAITON_LEVEL:1 switch set. Some subprograms must be inlined and inlining is only honored at OPTIMIZATION_LEVEL > 0.
Known LimitationsThe known limitations of this release are described below. Note that the limitations also applicable to the native Apex product are listed in the release notes for the native product, which is a separate document. Workarounds are included where applicable.
Upgrade to new Release
The Control > Maintenance > Upgrade to New Release dialog does not work for Apex Embedded. Users can upgrade views using Control > Maintenance > Remodel. Select New Model then select the Replace Switches button.
Array Storage Allocation for Apex 3.0.1 and 3.0.2
In some cases, arrays that are declared constant and are initialized with calculated values are allocated storage dynamically instead of from the constant memory segment.
Configuration Pragmas for Apex 3.0.0, 3.0.1 and 3.0.2
In the future, Suppress (ALL_CHECKS) will be accepted in both Ada95 and Ada 83 package specifications. This is the preferred form of the pragma.
However, in this release, pragma Suppress (ALL_CHECKS) does not always suppress all of the checks that this pragma applies to.
- In Ada 95, use pragma Suppress (ALL_CHECKS).
- In Ada 83, use pragma Suppress_ALL.
Ref of Constants
In machine code insertions, Apex does not create a concrete representation (a physical memory location) for scalar constants. For example, in the following code segment, the reference to S'Ref will lead to a compilation error.
S: constant boolean := true; Procedure Test_S(v: out boolean) is begin code_2'(lda, T0, S'Ref); code_2'(ld_b, T1, base(t0)); code_2'(move, V, T1); end Test_S;
In most circumstances, the workaround is to declare the constant as a variable:
Implicit Code Generation
In some situations, the Apex 2.4.2 compiler generated "implicit code" when evaluating Memory_Location'Ref operands. The implicit code generally evaluated the address in a temporary register, rather than just using the memory operand directly. The compiler front end did not recognize situations where the memory operand was simple enough that a temporary register (and the implicit code to evaluate the memory address referred to in the 'ref) was unnecessary. The resulting object code was correct, but generally less efficient, and inappropriate if implicit_code(off) was requested.
The 3.0.0 compiler handles more situations where it recognizes that implicit code is unnecessary. The 3.0.0 compiler, however, is still sometimes overly strict when evaluating the allowed types for operands in machine code statements, and may issue warnings that appear unnecessary given the context.
Ada Representation and Address Clauses
In certain situations, the Apex Ada compiler would generate code that accessed more bytes than required when reading or storing into a bit field inside a record declared with a representation clause and a "for use at" address location clause. The compiler would convert the bit accesses to a full word access, rather than using the smallest possible storage unit (1, 2, or 3 bytes), or the most "natural" storage unit (that is, a halfword if the bit field is 16 bits, and has an even byte address). This happens, because the compiler does not track the alignment attributes of the address used in the address clause.
For various technical reasons, the Apex compiler handles bit fields inside of objects declared with "for use at" clauses in the manner described above. The suggested workaround is to avoid using the "for use at" clause to overlay a record onto a physical location that is mapped to physical I/O devices. Instead, define an "image" copy of the register in RAM, modify that copy, and then use a machine_code procedure to write the this image copy in RAM to the actual physical memory address of the desired memory mapped I/O device. This approach will lead to more efficient code, because the compiler will properly keep track of the alignment attributes of the fields declared inside the memory image copy of the hardware register.
C/C++
Linking Ada 95 Code
If you link Ada 95 code that does not use standard output to C/C++ code that does attempt to use standard output, the C/C++ output will not print to the console. Workaround: Add "with Text_Io;" to your Ada 95 code and add the following line to be executed before any C/C++ calls are made that use standard output.
Text_Io.Put("");
This error does not occur when Ada 83 code is liked with C/C++ code.
Include the -cpp Option
If all the following are true, you should explicitly include the –cpp option on the command line when invoking apexinit:
- You are running the 2.4.1 version of Apex native.
- You installed the "Rational Apex Duo BASE" configuration of Apex native.
- You installed the Duo configuration of your Apex embedded product.
Adding the -cpp option in the above case will cause the C++ specific menu items to be displayed. In future releases of the Apex native product you should not need to explicitly include -cpp in the apexinit command line.
Inlined Machine Code
A reference to the V_BITS.BIT_AND function caused the rada compiler front-end to abort with an assertion error. This problem occurred on the inlining of any machine_code procedure that referred directly to hard-coded parameter registers (e.g., a0, a1). The workaround was to disable auto-inlining by using Optimization Level 1, and to refer to the out-of-line bit operations in the V_BITS package. A related problem is that the compiler front-end had difficulty in expanding machine_code procedures inline, and in particular, handling <parameter_register>'ref operands. The workaround was to refer to out-of-line machine_code procedures, and to avoid auto-inlining by avoiding Optimization Level 2.
Most problems with inlining "machine code" procedures have been fixed in 3.0.0. Some problems remain. For example, there are problems in expanding <register'ref> references when parameter registers are referenced inside of implicit functions. Auto-inlining of machine code procedures is now disabled at all levels of optimization. It should be safe to use Optimization Level 2 (it had to be avoided in 2.4.2), with the knowledge that machine_code procedures will not be auto-inlined.
Drag and Drop
You can't Drag-n-Drop target to the Selected Target text area in Target Control dialog box. Work Around: Use the Select Target button and OK or Apply.
Defects ResolvedProblems fixed in the base Apex product are listed in the release notes for the base product.
Refer to your product online documentation, Help > Manuals for the very latest updates to release notes
| Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2001, Rational Software Corporation. All rights reserved. |
| |
|
|
|
|
|
 |
 |