VHDL Issue Number:        2129

Language_Version          Accellera Standard VHDL-2006-D3.0
Classification            Language Definition Problem
Summary                   bad requirements to check exprs with access type sub exprs
Relevant_LRM_Sections     Section 6.1 Names in which it states:

    If the type of the prefix is an access type, the evaluation of the
    prefix includes the determination of the object designated by the
    corresponding access value. In such a case, it is an error if the
    value of the prefix is a null access value.

Related_Issues            
Key_Words_and_Phrases     
Authors_Name              John Shields
Authors_Phone_Number      503-685-0837
Authors_Fax_Number        
Authors_Email_Address     john_shields@mentor.com
Authors_Affiliation       Mentor Graphics, Inc.
Authors_Address1          8005 SW Boeckman Rd.
Authors_Address2          Wilsonville, OR 97070
Authors_Address3          

Current Status:           Submitted

Superseded By:

------------------------
Date Submitted:           17 January 2008
Date Analyzed:            27 February 2008
Author of Analysis:       Ajayharsh Varikat
Revision Number:          0
Date Last Revised:

Description of Problem
----------------------

The implication of this appears to be that in the runtime evaluation
of expressions, every subexpression that dereferences an access type
must be checked for null.  In an example like this:
    
    entity top is
    end top;
    
    architecture arch of top is
        type intlistelement;
        type intlistpointer is access intlistelement;
    
        type intlistelement is record
            element : integer;
            nextelem : intlistpointer;
        end record intlistelement;
    
        procedure increment (N: Integer ::   1) is
            variable countptr:intlistpointer;-- := new intlistelement'(0,null);
        begin
            countptr.all.element := countptr.all.element + (n-1);
        end procedure increment;
    
    begin
    
       p: process
       begin
           increment(5);
           wait;
       end process;
    
    end;
    
The rhs of the var assign stmt must check for null.  It is certainly
uncommon in other languages to require this kind of safety and there
is a serious performance penalty.

Proposed Resolution
-------------------

I would like to see this kind of error be erroneous.  It is
incongruous to me that the language requires this, but allows an
access variable to be deallocated and potentially cause erroneous
behavior.

VHDL would better serve users to provide the degree of freedom for
better performance. It is a related consideration to change the memory
allocation model to employ garbage collection, which would go along
way to improve the safety of access types and dynamic data.  These
things will take on increased significance if VHDL make better use of
dynamic data in verification scenarios.

VASG-ISAC Analysis & Rationale
------------------------------

In this analysis we use the term "dereference" to denote the process 
of determining the object designated by an access value. 

The LRM requires compliant tools to report an error if a null 
access value is dereferenced. This may require a simulation time 
check whenever an access value is dereferenced. As the submitter 
points out, there is a performance cost involved.

At the same time, making this erroneous and avoiding the null value 
check may result in a crash or undefined behavior that is often
difficult for a tool user to debug. 

The overhead in doing these checks may not be significant in most 
real-life situations, because:    
    a) the check is usually only a small part of the 
       operations typically done on an access value
    b) implementations can often do ingelligent analysis to avoid or 
       minimize checks in commonly executed parts of code
    c) where performance is critical, implementations may provide 
       non-compliant options to suppress these checks

The ISAC feels that the cons outweigh the pros here, and hence it is 
not desirable to relax this and make it an erroneous condition.

There is a related aspect of this issue that the LRM does not 
address. A variable of an access type may be copied to another, and
one of them deallocated. This would result in the deallocated variable 
getting a null value, but the other variable would retain it's value.
The LRM does not define what should happen if this (non-null) 
variable is dereferenced. It is difficult for an implementation
to detect such dereferencing, and hence this should clearly be an 
erroneous situation. 

Avoiding explicit deallocation and moving to a garbage collection 
model is a way to avoid both the issues discussed above. This should
be considered for future revisions of the standard.


VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------
No change with regard to dereferencing null access values. 

Dereferencing an access value where the designated object has
already been deallocated should be treated as erroneous.

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
Consider a garbage-collection model for dynamic memory allocation.
Forward to language committee.