![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Building Semantic Characteristics This chapter focuses on modeling the semantic characteristics of the target compiler. The first part of the chapter deals with the general types used to describe semantic characteristics, followed by sections on the specific semantic characteristics that can be modeled. The reader will be able to customize the RCI to handle semantics for a specific target compilation system.
Apex does target-specific semantic checking when you analyze an Ada unit in an RCI view. Because this operation takes place entirely on the host, with no communication to the target compiler, you must provide a description of the target-compiler-dependent aspects of Ada semantic checking.
(The first steps in creating the semantic characteristics are described in Building Your Customization.)
Note: Rational may be able to provide additional information to help with customization for a particular target compilation platform or vendor compiler. Before you begin a customization, contact your Rational representative for more information.
When you customize semantics, you define the semantic characteristics of pragmas, attributes, and representation clauses. This chapter takes you through the steps to create the semantic characteristics from basic components. Figures show the specifications that you use to define semantic characteristics.
The main sections in this chapter are:
Illustrates the top-level specification for each of the semantic components: attributes, pragmas and rep_specs.
- Basic Data Types
Describes the basic components used to build semantic characteristics.
- Completing Semantic Characteristics
Describes how to specify semantic characteristics of the semantic components:
Overview of Semantic CharacteristicsThe figures below provide overviews of the semantics structures. RCI Specification Language Notation reviews the notation used in the figures in this chapter.
Figure 24 Top Level Semantic Characteristics Specification
( RCI_CUSTOMIZATION < ADA_83 | ADA_95 > #id# < ( PRAGMAS ...) | ( ATTRIBUTES ...) | ( REP_SPECS ...) > )Figure 25 Top Level Pragmas Specification
( PRAGMAS ( ADA_PRAGMAS ...) ( TARGET_PRAGMAS ...) ( INTERFACE_LANGUAGES ...) )Figure 26 Top Level Attributes Specification
( ATTRIBUTES { ( ATTRIB #id# ( ATTR_PREFIX ...) { ( ATTR_PARAM ...) } ( ATTR_RESULT ...) [IS_STATIC #string#] ) } )Figure 27 Top Level Representation Clauses Specification
( REP_SPECS { ( ADDRESS_CLAUSE ...) } { ( STORAGE_SIZE ...) } [CHECK_REPRESENTATION_CLAUSE_NAMES] [ALLOW_MODULAR_TYPES] )
Basic Data TypesBasic data types are used to define type checking for arguments and return values for pragmas, attributes, and representation clauses.
- Types defined in this section:
- Type_Set
- Object_Set
- Miscellaneous_Name_Set
- Expression
Defining Type_Set
A type set describes the valid types for a given argument. For example, in the statement 'pragma foo (bar);', where bar names a type, you use a type set in the definition of pragma 'foo' to describe what types bar can be. Also, in the expression foo'bar(baz), type sets are used to describe the allowed types of both foo and baz.
An omitted type set means that no types are allowed.
Figure 28 shows the complete specification for type set. The sections following describe the components of type set:
- Enforced_Type_Restrictions
- Valid_Structural_Types
- Valid_Textual_Types
- Required_Pragmas
- Prohibited_Pragmas
Figure 28 Type Set Specification
( VALID_TYPES [ ( ENFORCED_TYPE_RESTRICTIONS [NO_SUBTYPES] [NO_PRIVATE_TYPES] [NO_LIMITED_PRIVATE_TYPES] [NO_DERIVED_TYPES] [NO_CLASS_WIDE_TYPES] [NO_CONTROLLED_TYPES] [NO_LIMITED_TYPES] [NO_PRIVATE_EXTENSIONS] [NO_SPECIFIC_TYPES] [NO_TYPE_EXTENSIONS] ) ] [ ( VALID_STRUCTURAL_TYPES [POOL_SPECIFIC_ACCESS_TYPE] [ARRAY_TYPE] [ENUMERATION_TYPE] [INTEGER_TYPE] [FIXED_POINT_TYPE] [FLOATING_POINT_TYPE] [FORMAL_DISCRETE_TYPE] [FORMAL_FIXED_TYPE] [FORMAL_FLOAT_TYPE] [FORMAL_INTEGER_TYPE] [RECORD_TYPE] [TASK_TYPE] [UNIVERSAL_INTEGER_TYPE] [UNIVERSAL_FIXED_TYPE] [UNIVERSAL_REAL_TYPE] [ACCESS_TO_SUBPROGRAM] [DECIMAL_FIXED_POINT_TYPE] [FORMAL_DECIMAL_FIXED_TYPE] [FORMAL_MODULAR_TYPE] [FORMAL_TAGGED_TYPE] [GENERAL_ACCESS_TO_CONSTANT] [GENERAL_ACCESS_TO_VARIABLE] [MODULAR_TYPE] [PROTECTED_TYPE] [STRING_TYPE] [TAGGED_TYPE] ) ] [ ( VALID_TEXTUAL_TYPES {#id#} ) ] [ ( REQUIRED_PRAGMAS {#id#} ) ] [ ( PROHIBITED_PRAGMAS {#id#} ) ] )Enforced_Type_Restrictions
Enforced_Type_Restrictions defines miscellaneous restrictions on the valid types for an argument or attribute prefix. Some of the restrictions apply only to ada95 customizations, the rest apply to either ada83 or ada95.
- NO_SUBTYPES
- NO_PRIVATE_TYPES
- NO_LIMITED_PRIVATE_TYPES
- NO_DERIVED_TYPES
- NO_CLASS_WIDE_TYPES -- ada95
- NO_CONTROLLED_TYPES -- ada95
- NO_LIMITED_TYPES -- ada95
- NO_PRIVATE_EXTENSIONS -- ada95
- NO_SPECIFIC_TYPES -- ada95
- NO_TYPE_EXTENSIONS -- ada95
Valid_Structural_Types
Valid_Structural_Types is a list of the general structural categories allowed for argument types and attribute prefix types. Unless otherwise noted, the structural type kinds apply to both ada83 and ada95 customizations.
Valid_Structural_Types are only checked if the type under consideration fails to match one of the Valid_Textual_Types.
- POOL_SPECIFIC_ACCESS_TYPE -- formerly "access_type"
- ARRAY_TYPE
- ENUMERATION_TYPE
- INTEGER_TYPE
- FIXED_POINT_TYPE
- FLOATING_POINT_TYPE
- FORMAL_DISCRETE_TYPE
- FORMAL_FIXED_TYPE
- FORMAL_FLOAT_TYPE
- FORMAL_INTEGER_TYPE
- RECORD_TYPE
- TASK_TYPE
- UNIVERSAL_INTEGER_TYPE
- UNIVERSAL_FIXED_TYPE
- UNIVERSAL_REAL_TYPE
- ACCESS_TO_SUBPROGRAM -- ada95
- DECIMAL_FIXED_POINT_TYPE -- ada95
- FORMAL_DECIMAL_FIXED_TYPE -- ada95
- FORMAL_MODULAR_TYPE -- ada95
- FORMAL_TAGGED_TYPE -- ada95
- GENERAL_ACCESS_TO_CONSTANT -- ada95
- GENERAL_ACCESS_TO_VARIABLE -- ada95
- MODULAR_TYPE -- ada95
- PROTECTED_TYPE -- ada95
- STRING_TYPE -- ada95
- TAGGED_TYPE -- ada95
Valid_Textual_Types
Valid_Textual_Types is a list of type names that are allowed for an argument or an attribute prefix. Examples include: "Integer", "System.Address", "Text_Io.Count".
Only types from predefined units are allowed.
Visibility to package Standard is implicit; you can use "Character" rather than "Standard.Character".
Note that Enforced_Type_Restrictions must hold when the type under consideration is derived in some manner from one of the Valid_Textual_Types, but do not apply to the textual type itself. For example, if the No_Derived_Types restriction is present, and "System.Address" is a Valid_Textual_Type, then
type T is new System.Address; pragma Foo (T);
pragma Foo (System.Address);
subtype T is System.Address; pragma Foo (T);are not, regardless of whether System.Address is a derived type.
Required and Prohibited Pragmas
Required_Pragmas and Prohibited_Pragmas are lists of pragma names that must or must not be applied to the type under consideration to make it legal.
This check is not made on any of the Valid_Textual_Types or their ancestors.
Defining Object_Set
An Object_Set describes the allowed Ada objects for a given argument or attribute prefix.
Object_Sets are not used to describe expressions, even though objects can be expressions.
A null Object_Set means that no objects are allowed.
Figure 29 shows the specification for Object_Set.
An Object_Set consists of the following items:
- Valid_Kinds: a list of the kinds of objects allowed.
- CONSTANT_KIND
- DISCRIMINANT
- IN_OUT_PARAMETER
- IN_PARAMETER
- ITERATION_VARIABLE
- NAMED_NUMBER
- OUT_PARAMETER
- VARIABLE
- Valid_Types: a type set which describes the allowed types for the object.
- Required and Prohibited Pragmas: list of pragma names which must or must not be applied to the object.
Figure 29 Specification for Object_Set
( VALID_OBJECTS ( VALID_KINDS [CONSTANT_KIND] [DISCRIMINANT] [IN_OUT_PARAMETER] [IN_PARAMETER] [ITERATION_VARIABLE] [NAMED_NUMBER] [OUT_PARAMETER] [VARIABLE] ) [ ( VALID_TYPES ...) ] [ ( REQUIRED_PRAGMAS {#id#} ) ] [ ( PROHIBITED_PRAGMAS {#id#} ) ] )Defining Miscellaneous_Name_Set
A Miscellaneous_Name_Set describes Ada names other than types or objects, such as functions, exceptions, and generics, which are valid for pragma arguments, attribute prefixes or address clauses.
Figure 30 shows the specification for Miscellaneous_Name_Set.
Note that since enumeration_literals, functions, procedures, and entries can be overloaded, some miscellaneous names are ambiguous.
A null Miscellaneous_Name_Set means that no miscellaneous names are allowed.
A Miscellaneous_Name_Set consists of the following components:
- Valid_Kinds: which miscellaneous names are valid.
- FUNCTION_KIND
- PACKAGE_KIND
- PROCEDURE_KIND
- TASK_KIND
- ENTRY_KIND
- EXCEPTION_KIND
- ENUMERATION_LITERAL_KIND
- RECORD_COMPONENT_KIND
- GENERIC_PACKAGE_KIND
- GENERIC_PROCEDURE_KIND
- GENERIC_FUNCTION_KIND
- GENERIC_FORMAL_PROCEDURE
- GENERIC_FORMAL_FUNCTION
- LABEL_KIND
- NAMED_STATEMENT_KIND
- PROTECTED_FUNCTION -- ada95 only
- PROTECTED_PROCEDURE -- ada95 only
- Ambiguity_Allowed: include if ambiguous miscellaneous names are permitted for the given argument.
- Required and Prohibited Pragmas:
Which pragmas must or must not be applied to the Miscellaneous_Name_Set.
Figure 30 Miscellaneous_Name_Set Specification
( VALID_MISC_NAMES ( VALID_MISC_NAME_KINDS [FUNCTION_KIND] [PACKAGE_KIND] [PROCEDURE_KIND] [TASK_KIND] [ENTRY_KIND] [EXCEPTION_KIND] [ENUMERATION_LITERAL_KIND] [RECORD_COMPONENT_KIND] [GENERIC_PACKAGE_KIND] [GENERIC_PROCEDURE_KIND] [GENERIC_FUNCTION_KIND] [GENERIC_FORMAL_PROCEDURE] [GENERIC_FORMAL_FUNCTION] [LABEL_KIND] [NAMED_STATEMENT_KIND] [PROTECTED_FUNCTION] [PROTECTED_PROCEDURE] ) [AMBIGUITY_ALLOWED] [ ( REQUIRED_PRAGMAS {#id#} ) ] [ ( PROHIBITED_PRAGMAS {#id#} ) ] )Defining Expressions
Expressions are used to describe valid pragma and attribute arguments.
An expression is represented as a type name and an optional static constraint.
Figure 31 shows the specification for expression.
If an expression has no static constraint and violates the bounds of the expression type itself, a warning is produced.
Any_Expr means that no information is available about the set of allowed expressions and thus all expressions are allowed.
Figure 31 Expression Specification
< ANY_EXPR | ( EXPR #id# -- The Type [ ( EXPR_CONSTRAINT < ( INTEGER_FORM LO #string# HI #string# ) | ( REAL_FORM LO #string# HI #string# ) | ( STRING_FORM ) | ( OTHER_FORM ) > ) ] ) >An expression consists of the following components:
- The type of the expression (a string).
- Expression_Constraint: Hi, Lo: strings which hold the range of the expression, for scalar expressions that must be static.
Customizing PragmasThis section describes how to define target compiler pragmas for semantic checking by the host.
There are two categories of pragmas that a target compiler can recognize:
- LRM-predefined pragmas
- Compiler-specific pragmas
- Gathering information about pragmas
- Building the pragma specification
- Specifying compiler-specific pragmas
- Specifying LRM-predefined pragmas
Gathering Information About Pragmas
- Compiler Guide and Reference for your target compiler
- LRM, Appendix F for your target compiler
- rci_pragma.spec from one of the example customization compiler key views.
Pragma Specification
Figure 25 shows the top-level specification for Pragma Characteristics, which are placed in the rci_pragma.spec file in the compiler key. Figure 32, Figure 33, Figure 34, Figure 35 and Figure 36 show the specifications of the component parts of the Pragma specification.
Figure 32 Ada Pragmas Specification
( ADA_PRAGMAS [CONTROLLED_PRAGMA] [ELABORATE_PRAGMA] [INLINE_PRAGMA] [INTERFACE_PRAGMA] [LIST_PRAGMA] [MEMORY_SIZE_PRAGMA] [OPTIMIZE_PRAGMA] [PACK_PRAGMA] [PAGE_PRAGMA] [PRIORITY_PRAGMA] [SHARED_PRAGMA] [STORAGE_UNIT_PRAGMA] [SUPPRESS_PRAGMA] [SYSTEM_NAME_PRAGMA] )Figure 33 Target Pragmas Specification
( TARGET_PRAGMAS { ( PRAGMA_DESCRIPTOR #id# ( PRAGMA_LOC ... ) LAST_REQUIRED_ARG #natural# { ( PRAGMA_ARG ...) } ) } )Figure 34 Pragma Locations Specification
( PRAGMA_LOC [CONTEXT_CLAUSE] [COMP_UNIT] [STATEMENT] [DECLARATION] [TASK_SPEC] [CONFIGURATION] [PROTECTED_SPEC] [RECORD_SPEC] )
Figure 35 Pragma Argument Specification
( PRAGMA_ARG < ( PRAGMA_NAME_ARG #id# [ ( VALID_OBJECTS ...) ] [ ( VALID_MISC_NAMES ...) ] [ ( VALID_TYPES ...) ] [ ( VALID_SPECIAL_IDENTIFIERS {#id#} ) ] | ( VALID_EXPRESSIONS #id# ( EXPR ...) ) | ANY_ARG > )Figure 36 Interface_Languages Specification
( INTERFACE_LANGUAGES {#string#} )Building Pragmas
The Pragma Characteristics contain the following components:
- Supported_Ada_Pragmas: List of supported Ada pragmas (see Figure 32 for the correct order).
- Target_Pragmas: List of target compiler pragmas (see Figure 33 for the specification).
- Interface_Languages: list of language names (strings). If pragma Interface is supported, list the set of languages allowed. See Figure 36 for the specification.
e.g. ( Interface_Languages "Assembly" "C" "Fortran" )To customize pragmas, edit the file rci_pragmas.spec in the compiler key, create the list of supported Ada pragmas, the list of target pragmas and the list of interface languages.
The following sections deal with creating the lists of supported Ada pragmas and target pragmas.
Defining Pragmas
Supported Ada Pragmas
The list of supported Ada_Pragmas indicates which of the Ada LRM predefined pragmas the target compiler recognizes.
Target Pragmas
The list of target pragmas is the list of non-lrm pragmas recognized by the target compiler.
Target Pragma definition includes:
- Id: the name of the target compiler pragma (double-quoted string).
- Valid_Locations: list of locations where the pragma is allowed selected from: Context_Clause, Comp_Unit, Statement, Declaration, Task_Spec, Configuration, Protected_Spec, Record_Spec.
- Last_Required_Argument: the index of the last required argument for the pragma (i.e., the number of required arguments). The required arguments must appear first in the argument list; arguments that follow the last required argument in the list are optional. Use 0 if all arguments are optional.
- Arguments: list of valid arguments for the pragma.
Pragma Arguments
RCI deals with two kinds of pragma arguments: name arguments and expression arguments.
- Name arguments are for those arguments that are important for their identity rather than their value. They are what Ada defines as "Names"; they return information if you use Visit. The Ada pragmas Pack, Elaborate, and Inline each have one Name Argument.
- Expression arguments are values. The Ada pragmas Memory_Size, Storage_Unit, and Priority each have one Expression Argument.
Some pragma arguments, such as the arguments to pragmas Optimize and List, can be pragma-dependent identifiers that appear nowhere else in the program. "Special Identifier" arguments are considered Name Arguments.
Object identifiers and function identifiers can represent both Names and Expressions. It is important to determine whether the pragma uses the value or the identity of the entity. A pragma is 'applied' to all entities supplied as Name Arguments of that pragma. This can be relevant if the pragma shows up somewhere as a 'Required' or 'Prohibited' pragma.
Target Pragma Example
The following example defines the pragma Alignment for the example VADS customization:
( PRAGMA_DESCRIPTOR "Alignment" ( PRAGMA_LOC DECLARATION ) LAST_REQUIRED_ARG 2 ( PRAGMA_ARG ( PRAGMA_NAME_ARG "object" ( VALID_OBJECTS ( VALID_KINDS CONSTANT_KIND DISCRIMINANT IN_OUT_PARAMETER IN_PARAMETER ITERATION_VARIABLE NAMED_NUMBER OUT_PARAMETER VARIABLE ) ( VALID_TYPES ( VALID_STRUCTURAL_TYPES POOL_SPECIFIC_ACCESS_TYPE ARRAY_TYPE ENUMERATION_TYPE INTEGER_TYPE FIXED_POINT_TYPE FLOATING_POINT_TYPE FORMAL_DISCRETE_TYPE FORMAL_FIXED_TYPE FORMAL_FLOAT_TYPE FORMAL_INTEGER_TYPE RECORD_TYPE TASK_TYPE UNIVERSAL_INTEGER_TYPE UNIVERSAL_FIXED_TYPE UNIVERSAL_REAL_TYPE ))))) ( PRAGMA_ARG ( VALID_EXPRESSIONS "Integer_Arg" ( EXPR "universal_integer"))))
Customizing AttributesCustomizing the RCI allows you to define target compiler attributes for target semantic checking by the host.
Figure 26 shows the top-level specification for target compiler attributes.
To customize, edit the rci_attrib.spec file in the compiler key.
Gathering Information About Attributes
- Compiler Guide and Reference for your target compiler
- LRM, Appendix F for your target compiler
- rci_attrib.spec from one of the example customizations.
The specifications for the component parts of attributes are shown in the following figures:
Figure 38 Attribute Prefix Specification
( ATTR_PREFIX [object_set] [miscellaneous_name_set] [type_set] )Figure 39 Attribute Parameter Specification
( ATTR_PARAM < IS_PREFIX_TYPE | ( EXPR ...) > [REQUIRED] )Figure 40 Attribute Result Specification
( ATTR_RESULT < TYPE_RESULT | VALUE_RESULT < IS_PREFIX_TYPE | #id# > | RANGE_RESULT < IS_PREFIX_TYPE | #id# > | SUBPROGRAM_RESULT < IS_PREFIX_TYPE | #id# > > )Defining Attributes
For each target compiler attribute you must define the following components:
- Id: the name of the target compiler attribute.
- Attr_Prefix: the prefix of the attribute.
Example: In the expression Foo'Bar, the prefix is foo. The Attr_Prefix specifies the objects, miscellaneous names and types valid for Foo.
A null prefix means that the semantics checker should place no restrictions on a prefix for the given attribute.
- Attr_Result: the result of the target compiler attribute. Results can be ranges, types, values or subprograms.
For example, Integer'Base returns a type, Integer'First returns a value, Some_Array'Range returns a range and Integer'image returns a subprogram. If the attribute returns a range, value or subprogram, then if the type of that range, value or subprogram return value must match the prefix type, then the Attr_Result should include IS_PREFIX_TYPE; otherwise the return value should be the name of the return type.
Note: in most cases, if an attribute has parameters, that attribute is subprogram-valued. The exceptions to this rule are not common outside of LRM-defined attributes, such as `First when applied to a multi-dimensioned array type or object, so most target compiler attributes can be expected to obey this rule.
- Attr_Param list: the parameters of the attribute. Some attributes require parameters whose type matches the prefix type (e.g., Some_Enum'Image(A), where A must be a value of type Some_Enum). In that case the Attr_Param specification includes IS_PREFIX_TYPE. Other parameters need to be treated as expressions so the Attr_Param specification includes an expression.
Modifying the Attribute Specification
Use these steps to modify the specification:
- 1 . Edit the rci_attr.spec file in your customization compiler key view.
- 2 . Add your list of attributes to the attribute list.
Attribute Example
The following example defines the overloaded `Ref attribute for the example VADS customization:
-- 'Ref has two permitted forms, X'Ref and System.Address'Ref(N) -- -- System.Address'Ref(N) - Used anywhere to convert the -- Universal_Integer value N to an Address. -- Returns a type of System.Address. -- N must be a static value of type Universal_Integer. -- ( ATTRIB "Ref" ( ATTR_PREFIX ( VALID_TYPES ( ENFORCED_TYPE_RESTRICTIONS NO_SUBTYPES NO_PRIVATE_TYPES NO_LIMITED_PRIVATE_TYPES NO_DERIVED_TYPES NO_SPECIFIC_TYPES ) ( VALID_TEXTUAL_TYPES "System.Address" ))) ( ATTR_PARAM ( EXPR "Universal_Integer" ( EXPR_CONSTRAINT ( INTEGER_FORM LO "-2147483648" HI "2147483647" ) ))) ( ATTR_RESULT VALUE_RESULT "System.Address" ) )
-- X'Ref - Used only in machine_code procedures. Where X is -- either a constant, variable, procedure, function, or label. -- Returns a value of type Machine_Code.Operand. -- May be used only to designate an operand within a code -- statement. -- ( ATTRIB "Ref" ( ATTR_PREFIX ( VALID_OBJECTS ( VALID_KINDS CONSTANT_KIND IN_OUT_PARAMETER IN_PARAMETER OUT_PARAMETER VARIABLE ) ( VALID_TYPES ( VALID_STRUCTURAL_TYPES POOL_SPECIFIC_ACCESS_TYPE ENUMERATION_TYPE INTEGER_TYPE FIXED_POINT_TYPE FLOATING_POINT_TYPE FORMAL_DISCRETE_TYPE FORMAL_FIXED_TYPE FORMAL_FLOAT_TYPE FORMAL_INTEGER_TYPE RECORD_TYPE TASK_TYPE UNIVERSAL_INTEGER_TYPE UNIVERSAL_FIXED_TYPE UNIVERSAL_REAL_TYPE ) ( VALID_TEXTUAL_TYPES "System.Address" ))) ( VALID_MISC_NAMES ( VALID_MISC_NAME_KINDS FUNCTION_KIND PROCEDURE_KIND ENUMERATION_LITERAL_KIND GENERIC_PROCEDURE_KIND GENERIC_FUNCTION_KIND GENERIC_FORMAL_PROCEDURE GENERIC_FORMAL_FUNCTION LABEL_KIND ) AMBIGUITY_ALLOWED )) ( ATTR_RESULT VALUE_RESULT "Machine_Code.Operand" ))
Customizing Representation ClausesThis section describes how to define target compiler representation specifications. You can define limits on storage size and place restrictions on address clause usage.
Figure 27 shows the top level specification for rep specs.
Gathering Information About Representation Clauses
- Compiler Guide and Reference for your target compiler
- LRM, Appendix F for your target compiler
- rci_rep_spec.spec from the VADS or GNAT example customization compiler key view.
Defining Representation Clause Specifications
The Representation clause specification goes in the file rci_rep_specs.spec in the compiler key.
The components of the Representation Clause Specification are shown in Figure 41 and Figure 42.
Storage Size Data
Storage_Size_Data describes the restrictions placed on the usage of storage_size representation clauses. Omission of Storage_Size_Data means that no target-dependent checks will be made on storage_size specifications.
Figure 41 Storage Size Specification
( STORAGE_SIZE TASK_UPPER_BOUND #string# ACCESS_UPPER_BOUND #string# [IS_ALLOWED_FOR_TASKS] [IS_ALLOWED_FOR_ACCESS_TYPES] [IS_ALLOWED_WITH_SIZE_SPECS] )Address Clause Data
Address_Clause_Data describes the restrictions placed on the usage of address representation clauses.
Figure 42 Address Clause Specification
( ADDRESS_CLAUSE [ ( VALID_OBJECTS ...) ] [ ( VALID_MISC_NAMES ...) ] )Rep Clause Example
This example specifies the rep clauses for an I386_PMVMSDDC customization:
( RCI_CUSTOMIZATION Ada_83 "i386pmvmsddc" ( REP_SPECS ( ADDRESS_CLAUSE ( VALID_OBJECTS ( VALID_KINDS CONSTANT_KIND DISCRIMINANT IN_OUT_PARAMETER IN_PARAMETER ITERATION_VARIABLE NAMED_NUMBER OUT_PARAMETER VARIABLE ) ( VALID_TYPES ( VALID_STRUCTURAL_TYPES POOL_SPECIFIC_ACCESS_TYPE ARRAY_TYPE ENUMERATION_TYPE INTEGER_TYPE FIXED_POINT_TYPE FLOATING_POINT_TYPE FORMAL_DISCRETE_TYPE FORMAL_FIXED_TYPE FORMAL_FLOAT_TYPE FORMAL_INTEGER_TYPE RECORD_TYPE TASK_TYPE UNIVERSAL_INTEGER_TYPE UNIVERSAL_FIXED_TYPE UNIVERSAL_REAL_TYPE ))) ( VALID_MISC_NAMES ( VALID_MISC_NAME_KINDS ENTRY_KIND ))) ( STORAGE_SIZE TASK_UPPER_BOUND "16#1_0000_0000#" ACCESS_UPPER_BOUND "16#1_0000_0000#" IS_ALLOWED_FOR_TASKS IS_ALLOWED_FOR_ACCESS_TYPES IS_ALLOWED_WITH_SIZE_SPECS ) CHECK_REPRESENTATION_CLAUSE_NAMES ALLOW_MODULAR_TYPES ) )
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |