</pre>
<p>
<h4>NOTES</h4>
<p>1--It follows from the visibility rules that a subprogram declaration must be given if a call of the subprogram occurs textually before the subprogram body, and that such a declaration must occur before the call itself.
<p>2--The preceding  rules concerning pure function subprograms, together with the fact that function parameters may only be of mode <b>in</b>, imply that a pure function has no effect other than the computation of the returned value.  Thus, a pure function invoked explicitly as part of the elaboration of a declaration, or one invoked implicitly as part of the simulation cycle, is guaranteed to have no effect on other objects in the description.
<p>3--VHDL does not define the parameter-passing mechanisms for foreign subprograms.
<p>4--The declarative parts and statement parts of subprograms decorated with the 'FOREIGN attribute are subject to special elaboration rules.  See   <a href = "1076_12.HTM#12.3"> 12.3 </a>   and  <a href = "1076_12.HTM#12.4"> 12.4 </a>  .
<p>5--A pure function subprogram may not reference a shared variable.  This prohibition exists because a shared variable may not be declared in a subprogram declarative part and a pure function may not reference any variable declared outside of its declarative region.
<h2><a name="2.3">  <a href = "1076_2.HTM#2.3"> 2.3 </a>   Subprogram overloading</a></h2>
<p>Two formal parameter lists are said to have the same <i>parameter type profile</i> if and only if they have the same number of parameters, and if at each parameter position the corresponding parameters have the same base type.  Two subprograms are said to have the same <i>parameter and result type profile</i> if and only if both have the same parameter type profile, and if either both are functions with the same result base type or neither of the two is a function.
<p>A given subprogram designator can be used in several subprogram specifications.  The subprogram designator is then said to be overloaded; the designated subprograms are also said to be overloaded and to overload each other.  If two subprograms overload each other, one of them can hide the other only if both subprograms have the same parameter and result type profile.
<p>A call to an overloaded subprogram is ambiguous (and therefore is an error) if the name of the subprogram, the number of parameter associations, the types and order of the actual parameters, the names of the formal parameters (if named associations are used), and the result type (for functions) are not sufficient to identify exactly one (overloaded) subprogram specification.
<p>Similarly, a reference to an overloaded resolution function name in a subtype indication is ambiguous (and is therefore an error) if the name of the function, the number of formal parameters, the result type, and the relationships between the result type and the types of the formal parameters (as defined in   <a href = "1076_2.HTM#2.4"> 2.4 </a>  ) are not sufficient to identify exactly one (overloaded) subprogram specification.
<p><i>Examples:</i>
<pre>--  Declarations of overloaded subprograms:

     <b>procedure</b> Dump(F: <b>inout</b> Text; Value: Integer);
     <b>procedure</b> Dump(F: <b>inout</b> Text; Value: String);

     <b>procedure</b> Check (Setup: Time; <b>signal</b> D: Data; <b>signal</b> C: Clock);
     <b>procedure</b> Check (Hold: Time; <b>signal</b> C: Clock; <b>signal</b> D: Data);

--  Calls to overloaded subprograms:

     Dump (Sys_Output, 12) ;
     Dump (Sys_Error, "Actual output does not match expected output") ;

     Check (Setup=>10 ns, D=>DataBus, C=>Clk1) ;
     Check (Hold=>5 ns, D=>DataBus, C=>Clk2);
     Check (15 ns, DataBus, Clk) ;
      --  Ambiguous if the base type of DataBus is the same type as the base type of Clk.
</pre>
<p>
<h4>NOTES</h4>
<p>
1--The notion of parameter and result type profile does not include parameter names, parameter classes, parameter modes, parameter subtypes, or default expressions or their presence or absence.
<p>2--Ambiguities may (but need not) arise when actual parameters of the call of an overloaded subprogram are themselves overloaded function calls, literals, or aggregates.  Ambiguities may also (but need not) arise when several overloaded subprograms belonging to different packages are visible.  These ambiguities can usually be solved in two ways: qualified expressions can be used for some or all actual parameters and for the result, if any; or the name of the subprogram can be expressed more explicitly as an expanded name (see   <a href = "1076_6.HTM#6.3"> 6.3 </a>  ).
<h3><a name="2.3.1">  <a href = "1076_2.HTM#2.3.1"> 2.3.1 </a>   Operator overloading</a></h3>
<p>The declaration of a function whose designator is an operator symbol is used to overload an operator.  The sequence of characters of the operator symbol must be one of the operators in the operator classes defined in   <a href = "1076_7.HTM#7.2"> 7.2 </a>  .
<p>The subprogram specification of a unary operator must have a single parameter.  The subprogram specification of a binary operator must have two parameters; for each use of this operator, the first parameter is associated with the left operand, and the second parameter is associated with the right operand.
<p>For each of the operators "+" and "-", overloading is allowed both as a unary operator and as a binary operator.
<p><a name="notes">NOTES</a>
<p>1--Overloading of the equality operator does not affect the selection of choices in a case statement or in a selected signal assignment statement; nor does it have an affect on the propagation of signal values.
<p>2--A user-defined operator that has the same designator as a short-circuit operator (that is, that overloads the short-circuit operator) is not invoked in a short-circuit manner.  Specifically, calls to the user-defined operator always evaluate both arguments prior to the execution of the function.
<p>3--Functions that overload operator symbols may also be called using function call notation rather than operator notation.  This statement is also true of the predefined operators themselves.
<p><i>Examples:</i>
<pre>     <b>type</b> MVL <b>is</b> ('0', '1', 'Z', 'X') ;

     <b>function</b> "and" (Left, Right: MVL) <b>return</b> MVL ;
     <b>function</b> "or" (Left, Right: MVL) <b>return</b> MVL ;
     <b>function</b> "not" (Value: MVL) <b>return</b> MVL ;

     <b>signal</b> Q,R,S: MVL ;

     Q &lt;= 'X' <b>or</b> '1';
     R &lt;= "or" ('0','Z');
     S &lt;= (Q <b>and</b> R) <b>or not</b> S;
</pre>
<h3><a name="2.3.2">  <a href = "1076_2.HTM#2.3.2"> 2.3.2 </a>   Signatures</a></h3>
<p>A signature distinguishes between overloaded subprograms and overloaded enumeration literals based on their parameter and result type profiles.  A signature can be used in an attribute name, entity designator, or alias declaration.
<pre>     signature ::=  [ [ type_mark { , type_mark } ] [ <b>return</b> type_mark ] ]
</pre>
<p>(Note that the initial and terminal brackets are part of the syntax of signatures and do not indicate that the entire right-hand side of the production is optional.)  A signature is said to <i>match</i> the parameter and result type profile of a given subprogram if and only if all of the following conditions hold:
<ul>
<p>--  The number of type marks prior to the reserved word <b>return</b>, if any, matches the number of formal parameters of the subprogram
<p>--  At each parameter position, the base type denoted by the type mark of the signature is the same as the base type of the corresponding formal parameter of the subprogram
<p>--  If the reserved word <b>return</b> is present, the subprogram is a function and the base type of the type mark following the reserved word in the signature is the same as the base type of the return type of the function, or the reserved word <b>return</b> is absent and the subprogram is a procedure
</ul>
<p>Similarly, a signature is said to match the parameter and result type profile of a given enumeration literal if the signature matches the parameter and result type profile of the subprogram equivalent to the enumeration literal, defined in   <a href = "1076_3.HTM#3.1.1"> 3.1.1 </a>  .
<p><i>Example:</i>
<pre>     <b>attribute</b> BuiltIn <b>of</b> "or" [MVL, MVL <b>return</b> MVL]: <b>function</b> <b>is</b> TRUE;
       --  Because of the presence of the signature, this attribute specification
       --  decorates only the "or" function defined in the previous section.

     <b>attribute</b> Mapping <b>of</b> JMP [<b>return</b> OpCode] : <b>literal</b> <b>is</b> "001";
</pre>
<h2><a name="2.4">  <a href = "1076_2.HTM#2.4"> 2.4 </a>   Resolution functions</a></h2>
<p>A resolution function is a function that defines how the values of multiple sources of a given signal are to be resolved into a single value for that signal.  Resolution functions are associated with signals that require resolution by including the name of the resolution function in the declaration of the signal or in the declaration of the subtype of the signal.  A signal with an associated resolution function is called a resolved signal (see  <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  ).
<p>A resolution function must be a pure function (see   <a href = "1076_2.HTM#2.1"> 2.1 </a>  ); moreover, it must have a single input parameter of class <b>constant</b> that is a one-dimensional,unconstrained array whose element type is that of the resolved signal.  The type of the return value of the function must also be that of the signal.  Errors occur at the place of the subtype indication containing the name of the resolution function if any of these checks fail (see   <a href = "1076_4.HTM#4.2"> 4.2 </a>  ).
<p>The resolution function associated with a resolved signal determines the <i>resolved</i> <i>value</i> of the signal as a function of the collection of inputs from its multiple sources.  If a resolved signal is of a composite type, and if subelements of that type also have associated resolution functions, such resolution functions have no effect on the process of determining the resolved value of the signal.  It is an error if a resolved signal has more connected sources than the number of elements in the index type of the unconstrained array type used to define the parameter of the corresponding resolution function.
<p>Resolution functions are implicitly invoked during each simulation cycle in which corresponding resolved signals are active (see   <a href = "1076_12.HTM#12.6.1"> 12.6.1 </a>  ).  Each time a resolution function is invoked, it is passed an array value, each element of which is determined by a corresponding source of the resolved signal, but excluding those sources that are drivers whose values are determined by null transactions (see   <a href = "1076_8.HTM#8.4.1"> 8.4.1 </a>  ).  Such drivers are said to be <i>off</i>.  For certain invocations (specifically, those involving the resolution of sources of a signal declared with the signal kind <b>bus</b>), a resolution function may thus be invoked with an input parameter that is a null array; this occurs when all sources of the bus are drivers, and they are all off.  In such a case, the resolution function returns a value representing the value of the bus when no source is driving it.
<p><i>Example:</i>
<pre>     <b>function</b> WIRED_OR (Inputs: BIT_VECTOR) <b>return</b> BIT <b>is</b>
       <b>constant</b> FloatValue: BIT := '0';
     <b>begin</b>
       <b>if</b> Inputs'Length = 0 <b>then</b>
                 --  This is a bus whose drivers are all off.
                 <b>return</b> FloatValue;
       <b>else</b>
                 <b>for</b> I <b>in</b> Inputs'Range <b>loop</b>
                            <b>if</b> Inputs(I) = '1' <b>then</b>
                                      <b>Return</b> '1';
                            <b>end If</b>;
                 <b>end Loop</b>;
                 <b>Return</b> '0';
       <b>end if</b>;
     <b>end function</b> WIRED_OR;
</pre>
<h2><a name="2.5">  <a href = "1076_2.HTM#2.5"> 2.5 </a>   Package declarations</a></h2>
<p>A package declaration defines the interface to a package.  The scope of a declaration within a package can be extended to other design units.
<pre>     package_declaration ::=
       <b>package</b> identifier <b>is</b>
               package_declarative_part
       <b>end</b> [ <b>package</b> ] [ <i>package</i>_simple_name ] ;

     package_declarative_part ::=
       { package_declarative_item }

     package_declarative_item ::=
        subprogram_declaration
       | type_declaration
       | subtype_declaration
       | constant_declaration
       | signal_declaration
       | <i>shared</i>_variable_declaration