TOC PREV NEXT INDEX DOC LIST MASTER INDEX



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.


Overview of Semantic Characteristics

The 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
Figure 25 Top Level Pragmas Specification
Figure 26 Top Level Attributes Specification
Figure 27 Top Level Representation Clauses Specification


Basic Data Types

Basic data types are used to define type checking for arguments and return values for pragmas, attributes, and representation clauses.

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:

Figure 28 Type Set Specification

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.

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.

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

is rejected, but

and

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:

Figure 29 Specification for Object_Set

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:

Figure 30 Miscellaneous_Name_Set Specification

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

An expression consists of the following components:


Customizing Pragmas

This 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:

This section describes:

Gathering Information About Pragmas

Documentation

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
Figure 33 Target Pragmas Specification
Figure 34 Pragma Locations Specification
Figure 35 Pragma Argument Specification
Figure 36 Interface_Languages Specification

Building Pragmas

The Pragma Characteristics contain the following components:

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:

Pragma Arguments

RCI deals with two kinds of pragma arguments: name arguments and expression arguments.

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:


Customizing Attributes

Customizing 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

The specifications for the component parts of attributes are shown in the following figures:

Figure 38 Attribute Prefix Specification
Figure 39 Attribute Parameter Specification
Figure 40 Attribute Result Specification

Defining Attributes

For each target compiler attribute you must define the following components:

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:


Customizing Representation Clauses

This 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

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

Address Clause Data

Address_Clause_Data describes the restrictions placed on the usage of address representation clauses.

Figure 42 Address Clause Specification

Rep Clause Example

This example specifies the rep clauses for an I386_PMVMSDDC customization:


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS