Language Change Specification for Create a Reference to Protected Types

LCS Number:	LCS-2016-014b
Version:	1 {22-Jan-2017}
Date:	22-Jan-2017
Status:	Draft
Author:	Patrick Lehmann Lieven Lemiengre
Email:	Main.PatrickLehmann Main.LievenLemiengre
Source Doc:	- - - -
Summary:	This LCS allows the retrieval of access values (references) to declared objects.

Voting Results: Cast your votes here

Yes:

1. Patrick Lehmann - 2017-01-22 - ver 1

No:

1. Thomas Preusser - 2017-01-22 - see comment
2. Martin Zabel - 2017-01-28 - see Thomas' comments
3. Peter Flake - 2017-02--02 - see comment
4. Martin Thompson- 2017-02-17 Version 2 - the comments indicate this needs more analysis than I have time to give, sorry
5. Mark Zwolinski - 2017-02-23 - This needs more thought. I agree with the sceptical comments of others.

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 1 - Abstain due to lack of personal time for review.

Style Notes

Changes are shown in red font.
Deletions are crossed out.
Deletions by other LCS' crossed out.
Editing or reviewing notes in green font.

Reviewing Notes

Currently, access values (references) can only be created by allocation ( a : new INTEGER'(5);= ). This LCS adds a 'access attribute.

This LCS also allows protected types to be passed as IN parameters and deprecates the INOUT mode.

Details of Language Change

4.2.2.2 Constant and variable parameters

[Reviewer note: It's a contradiction to pass a protected type by reference and request it to be of mode inout.]

For a subprogram having a parameter whose type is a protected type, the parameter is passed by reference. It is an error if the mode of the parameter is other than in or inout. It is a deprecated warning if the mode of the parameter is inout.

5.4.1 General

An object declared by an object declaration is created by the elaboration of the object declaration and is denoted by a simple name or by some other form of name. In contrast, objects that are created by the evaluation of allocators (see 9.3.7) have no simple name. Access to such an object is achieved by an access value returned by an allocator or by retrieving the access value by the attribute ACCESS; the access value is said to designate the object.

access_type_definition ::= access subtype_indication

For each access type, there is a literal null that has a null access value designating no object at all. The null value of an access type is the default initial value of the type. Other values of an access type are obtained by evaluation of a special operation of the type, called an allocator. Each such access value designates an object of the subtype defined by the subtype indication of the access type definition. This subtype is called the designated subtype and the base type of this subtype is called the designated type. The designated type shall not be a file type or a protected type.

An object declared to be of an access type shall be an object of class variable. An object designated by an access value is always an object of class variable.

The only form of constraint that is allowed after the name of an access type in a subtype indication is an array constraint or a record constraint. An access value belongs to a corresponding subtype of an access type either if the access value is the null value or if the value of the designated object satisfies the constraint.

Examples:

type ADDRESS is access MEMORY;
type BUFFER_PTR is access TEMP_BUFFER;

NOTE 1 -- An access value delivered by an allocator or attribute ACCESS can be assigned to several variables of the corresponding access type. Hence, it is possible for an object created by an allocator or object declaration to be designated by more than one variable of the access type. An access value can only designate an object created by an allocator; in particular, it cannot designate an object declared by an object declaration.

NOTE 2 -- If the type of the object designated by the access value is an array type or has a subelement that is of an array type, this object is constrained with the array bounds supplied implicitly or explicitly for the corresponding allocator.

NOTE 3 -- If the designated type is a composite type, it cannot have a subelement of a file type or a protected type (see 5.3.1).

5.4.2 Incomplete type declarations

The designated type of an access type can be of any type except a file type or a protected type (see 5.4.1). In particular, the type of an element of the designated type can be another access type or even the same access type. This permits mutually dependent and recursive access types. Declarations of such types require a prior incomplete type declaration for one or more types.

incomplete_type_declaration ::= type identifier ;

For each incomplete type declaration there shall be a corresponding full type declaration with the same identifier. This full type declaration shall occur later and immediately within the same declarative part as the incomplete type declaration to which it corresponds.

5.4.3 Allocation and deallocation of objects

Add an implicte deallocate/finalize method to protected types if an access type is generated. Call finalize, when the access type gets deallocated and the object is a protected type.)

10.6.2.1 General [in Simple variable assignments]

Prohibit assignment of access values to variables with a greater scope than the created object, unless it was created by an allocator.

16.2.2 Predefined attributes of types and objects

[Editor note: Insert the next table after table for O'SUBTYPE.]

V'access	Kind:	Access value
	Prefix:	Any prefix V that is appropriate for a variable object with a protected type PT, or an alias thereof.
	Result type:	Access value.
	Result:	The access value referencing the object denoted by prefix V.

An implicit access value conversion is required. Rule: it's OK if both access types denote the same subtype.

Annex F (Features under consideration for removal)

The following features are being considered for removal from a future version of the language.¹⁷ Accordingly, modelers should refrain from using them when possible:

• None
• Passing of subprogram parameters of class protected type as mode INOUT.

Comments

This may be used for taking the addresses of totally differently allocated objects. The underlying objects may reside on the stack or in static data areas rather than the heap. This implies a dramatic change and huge burden on tool implementors. Heap allocation and reference counting must be used for everything - or escape analysis must be performed for stack-allocated values - or you are buying into a mess of dangling pointers.

-- Thomas Preusser - 2017-01-22

TBP: This may be used for taking the addresses of totally differently allocated objects.

PL: Access types are still strong typed pointers and no void* like in C.

TBP: The underlying objects may reside on the stack or in static data areas rather than the heap.

PL: Protected types declared as shared variables are never allocated on a stack to fulfill the lifetime rule.

TBP: Heap allocation and reference counting must be used for everything ...

PL: Reference counting is not necessary, there are other techniques available e.g. garbage collection (GC). As requested by a high ranked proposal (position 30 of 104), I wrote LCS 030 allowing garbage collection.

TBP: ... or escape analysis must be performed for stack-allocated values ...

PL: References to protected types declared in e.g. processes can be passed to subprograms, as long as an access value is not assigned to a variable with greater scope or longer lifetime. (I'll add this rule as marked in blue).

-- Patrick Lehmann - 2017-01-22

PL: Access types are still strong typed pointers and no void* like in C.

TBP: I said differently allocated not differently typed.

PL: Protected types declared as shared variables are never allocated on a stack to fulfill the lifetime rule.

TBP: Protected types may be used for regular variables in a process, function or procedure as well.

PL: Reference counting is not necessary, there are other techniques available e.g. garbage collection (GC). As requested by a high ranked proposal (position 30 of 104), I wrote LCS 030 allowing garbage collection.

TBP: Reference counting was just an example. The underlying problem cannot be solved by GC either. With a static, scope-defined lifetime, you keep the door open for synthesis support. Tools like it when this information is explicit and need not be reconstructed and proven.

PL: References to protected types declared in e.g. processes can be passed to subprograms, as long as an access value is not assigned to a variable with greater scope or longer lifetime. (I'll add this rule as marked in blue).

TBP: This statement is too vague. Is this dynamically checked? Must the smaller scope be provable locally at compile time?

This proposal is too big a beast to be tackled just before the door's closing. I think it is worth to pursue but should be backed by thoroughly studying existing examples like Rust, which try to safely cope with those reference issues.

-- Thomas Preusser - 2017-01-23

VHDL is a simulation language, not a hi-performance systems language. Adding an ownership type system like Rust isn't worth the complexity it brings, garbage collection will be good enough and it will simplify things for the designer.

-- Lieven Lemiengre - 2017-01-23

Yet, you need to be precise in the specification to avoid room for interpretation and tool divergence. To "prohibit [the] assignment of access values to variables with a greater scope than the created object, unless it was created by an allocator" is a goal but not a firm ruling. Do you check this at run time? Are there static assignment rules? If so, which? Let GC take care of allocated objects. If you really want references to subsume objects created another way, make sure to create a consistent and precise solution. And for this, it is always good to learn from the achievements and mistakes of others.

-- Thomas Preusser - 2017-01-23

The unary & operator in C is dangerous, and this brings the danger to VHDL. It allows the lifetime of a pointer to exceed the lifetime of the object. It risks garbage collection of static or stack objects. It avoids enforcement of in/out restrictions.

-- Peter Flake - 2017-02-02