Language Change Specification for Interface Construct and Port Mode Configurations Proposal

Secondary LCS:

This LCS details the interface 'null' mode support required for a mode view interface construct at the RTL.

Voting Results: Cast your votes here

• Yes:
  1. Brent Hayhoe - 2017-03-13 - Version 1
  2. Steve Grout - 2017-03-16 - Version 1

• No:
  1. Jim Lewis - 2017-03-24 - Version 1
  2. Patrick Lehmann - 2017-03-27 - Version 1
  3. Rob Gaddi - 2017-03-30 - Version 1

• Abstain:
  1. Peter Flake - 2017-03-16 - Version 1 - see comment

Format Key

• LRM text is shown between single quotes '... P1076 LRM quoted text ...'
• Existing LRM text is shown in BLACK coloured font
• Additional LRM text is shown in RED coloured font
• Deleted LRM text is shown in RED with strike-through
• In order to try and emphasize text in italic font:
  • Italic font in existing LRM text is shown in GRAY italic font
  • Italic font in new LRM text is shown in ORANGE italic font
  • Italic font in deleted LRM text is shown in ORANGE with strike-through
• Editing instructions (and informative annotations) are shown in GREEN coloured font

Details of Language Change:

Annot: The following details the modifications to the LRM for the inclusion of a null mode which enables the termination of a composite object's element at an interface boundary, but disables the association of the element's actual part from its formal part in the mapping of the interface object instantiation.

LRM 4.2.2.1 Formal parameter lists

page 21 top

Edit: Replace the 1st paragraph beginning:

'For those parameters with modes, ...'

Edit: with the following paragraph:

'For those parameters with modes, the only modes that are allowed for formal parameters of a procedure are in, inout, and out. If the mode is in and no object class is explicitly specified, constant is assumed. If the mode is inout or out, and no object class is explicitly specified, variable is assumed. For a parameter of a composite type, a mode view indication is allowed, replacing the mode in order to specify the individual composite elements of the parameter. In addition to the allowable modes above, a mode view indication may also use the null mode.'

LRM 4.2.2.2 Constant and variable parameters

page 21 middle

Edit: Replace the 3rd paragraph beginning:

'For a nonforeign subprogram having a parameter whose type is an array or ...'

Edit: with the following paragraph:

'For a nonforeign subprogram having a parameter whose type is an array or record, an implementation may pass parameter values by copy, as for scalar types. In that case, after completion of the subprogram body, if the mode is inout or out, the value of each subelement of the formal parameter is only copied back to the corresponding subelement of the associated actual parameter if the subelement of the associated actual parameter is not forced. If a parameter of mode out is passed by copy, then the range of each index position of the actual parameter is copied in, and likewise for its subelements or slices. Alternatively, an implementation may achieve these effects by reference; that is, by arranging that every use of the formal parameter (to read or update its value) be treated as a use of the associated actual parameter throughout the execution of the subprogram call. The language does not define which of these two mechanisms is to be adopted for parameter passing, nor whether different calls to the same subprogram are to use the same mechanism. The execution of a subprogram is erroneous if its effect depends on which mechanism is selected by the implementation. The actual of a parameter subelement of mode null is neither updated by copy nor reference.'

LRM 4.10 Conformance rules

page 34 middle

Edit: Replace the 4th paragraph beginning:

'Two subprogram declarations are said to have ...'

Edit: with the following paragraph:

'Two subprogram declarations are said to have conforming profiles if and only if both are procedures or both are functions, the parameter and result type profiles of the subprograms are the same and, at each parameter position, the corresponding parameters have the same class and mode mode indication and class.'

LRM 5.3.2.2 Index constraints and discrete ranges

page 48 middle

Edit: Replace list item e) sublist item 3) with:

'  3)

• If the subtype index range is undefined, and the interface object is associated in whole (see 6.5.7.1) or is a subelement that is associated individually by a single association element other than one in which the formal designator is a slice name, then the index range of the object is obtained from the association element in the following manner:
  • For an interface object or subelement whose mode is in, inout, or linkage, or null, if the actual part includes a conversion function or a type conversion, then the result type of that function or the type mark of the type conversion shall define a constraint for the index range corresponding to the index range of the object, and the index range of the object is obtained from that constraint; otherwise, the index range is obtained from the object or value denoted by the actual designator.
  • For an interface object or subelement whose mode is out, buffer, inout, or linkage, or null, if the formal part includes a conversion function or a type conversion, then the parameter subtype of that function or the type mark of the type conversion shall define a constraint for the index range corresponding to the index range of the object, and the index range is obtained from that constraint; otherwise, the index range is obtained from the object denoted by the actual designator.
• For an interface object of mode inout or linkage, the index range determined by the first rule shall be identical to the index range determined by the second rule.'

LRM 6.5.2 Interface object declarations

page 73 middle

Edit: Replace the BNF productions with:

interface_object_declaration ::=
     interface_constant_declaration
   | interface_signal_declaration
   | interface_variable_declaration
   | interface_file_declaration

interface_constant_declaration ::=
     [ constant ] identifier_list : [ in ] subtype_indication [ := static_expression ]

interface_signal_declaration ::=
     [ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_expression ]

interface_variable_declaration ::=
     [ variable ] identifier_list : [ mode ] subtype_indication [ := static_expression ]

interface_file_declaration ::=
     file identifier_list : subtype_indication

mode ::= in | out | inout | buffer | linkage | null

page 73 middle

Edit: After the bullet point beginning:

'

• linkage. Reading and ...'

Edit: insert the following bullet point:

'

• null. The null mode is intended for use within the elements of an interface object of composite type as defined in the mode view declaration described in 6.5.2.1.
  The element of a formal of a composite interface object with a mode view defining its mode as null is disassociated from its actual in any instantiation of the interface. The actual cannot read nor update the formal and neither can the formal read nor update the actual.

page 80 bottom

Edit: After the bullet point beginning:

'  e) For a formal port of mode linkage, ...'

Edit: insert the following bullet point:

'  f) For a formal port of mode null, the associated actual may be a port of any mode.'

LRM Annex C Syntax summary

page 491

Edit: Replace the 'mode' BNF production with the following:

mode ::= in | out | inout | buffer | linkage | null                    [ยง 6.5.2]

LRM Annex I Glossary

page 572

Edit: Replace the 'mode' item with the following:

' mode: The direction of information flow through the port or parameter. Modes are in, out, inout, buffer, or linkage, or null. (6.5.2, 6.5.6.3)'

page 573

Edit: Insert after the 'nonpostponed process' item the following:

' null: The reserved word null may refer to its use as a literal in a null statement (10.14), as a literal in a null waveform element (10.5.2.2), as a literal defining a null access value for an access type or subtype (5.4.1, 9.3.2), or as a mode specifying a null mode (6.5.2, 6.5.6.3).'

Edit: Insert after the 'null array' item the following:

' null mode: A mode used within mode views, that disassociates the actual from the formal within the port/parameter mapping of a composite interface object. The actual cannot read, nor be updated by the formal. Similarly, the formal cannot read, nor be updated by the actual. (6.5.2, 6.5.6.3)'

Comments

I prefer the keyword 'open' to 'null', since an open formal is like an open actual.

-- Peter Flake - 2017-03-16

The 'null' keyword was chosen specifically to distinquish it from an 'open' port/parameter, because the port is neither 'open' on the formal side, nor on the actual side. In reality the port/parameter doesn't exist at all, but is just a lexical terminator for the composite element.

-- Brent Hayhoe - 2017-03-21