(r6) ProtectedTypeComposition < P1076

P1076 Web>Vhdl2019CollectedRequirements>ProtectedTypeComposition (revision 6) (raw view)~~EditAttach~~
---+ Composition with Protected Types

<br />%TOC%
---++ Proposal Information
   * State of this Proposal: Raw / Stream of Conscious
   * Current Owner: JimLewis, ...
   * Contributors: JimLewis, Main.PatrickLehmann, ...
   * Date Proposed: 2013-Jan-04
   * Date Last Updated: 2016-Feb-19
   * Priority:
   * Complexity:
   * Focus: Testbench
   * Related Issues: None
   * Competing Issues: None
---++ Requirement Summary

Simplify composition with protected types.

---++ Current Situation

Currently protected type declarations only allow:
<verbatim>protected_type_declarative_item ::= [§ 5.6.2]
    subprogram_declaration
    | subprogram_instantiation_declaration
    | attribute_specification
    | use_clause</verbatim>

As a result, to do composition with protected types requires creation of wrapper methods for each method that it is necessary to make visible.
<verbatim>package ScoreboardPkg ... is
    type ScoreboardPType is protected
        procedure SetMessage (NameIn : String) ;
        procedure WriteMessage ;
        ...

    end protected ScoreboardPType ;
end package ScoreboardPKg ; 
package body ScoreboardPkg is
    type ScoreboardPType is protected body
        variable Name : MessagePType ; 
        procedure SetMessage( NameIn : String) is 
        begin
            Name.SetMessage(NameIn) ; 
       end procedure SetMessage ; 
       procedure WriteMessage is
       begin
           Name.WriteMessage ; 
       end procedure WriteMessage ; 
       ...

    end protected ScoreboardPType ;
end package ScoreboardPKg ; </verbatim>

---++ Proposed Extension

Allow shared variables and aliases (to methods) to be included a protected type declarative region.
<verbatim>protected_type_declarative_item ::= [§ 5.6.2]
    subprogram_declaration
    | subprogram_instantiation_declaration
    | attribute_specification
    | use_clause
    | shared_variable_declaration
    | alias_declaration</verbatim>

---++ Resulting Code
<verbatim>package ScoreboardPkg ... is
    type ScoreboardPType is protected
        shared variable Name : MessagePType ; 
        alias SetMessage is Name.SetMessage [String] ;
        alias WriteMessage is Name.WriteMessage  ;
        ...

    end protected ScoreboardPType ;
end package ScoreboardPKg ; 
package body ScoreboardPkg is
    type ScoreboardPType is protected body
       ...

    end protected ScoreboardPType ;
end package ScoreboardPKg ; </verbatim>

---++ Additional Requirement 6/30/2016

Allow access by name:

<verbatim>varName.Name.SetMessage ;</verbatim>

---++ Semaphore Example:

Many code structures reuse an item from another code structure. The is demonstrated in the open source semaphore prototype implementation with local the variable Name : NamePType defined in the protected type body with methods SetName, GetName, IsSetName, and ClearName. Rather than these, it would be much easier to accomplish this by doing:
<verbatim>  type SemaphorePType is protected
    . . . 
   shared variable Name : NamePType ; 
  end protected SemaphorePType ;</verbatim>

Then calling the methods of Name by the following:
<verbatim>architecture A of E is 
  shared variable Semaphore : SemaphorePType ; 
  . . . 
begin

  TestProc : process
  begin
    Semaphore.Name.Set("Test1_SemaphoreA") ;   -- not necessary to be in a process
    . . . </verbatim>

If shorthand names are desirable, like provided in the package, It would be nicer to be able to create them with an alias instead:
<verbatim>  type SemaphorePType is protected
    . . . 
   shared variable Name : NamePType ; 
   -- For simple mapping.  Signature only required when it is otherwise ambiguous.
   alias GetName is Name.Get [return boolean] ;

   -- For more complicated mappings.  
   -- Intended to allow parameter reordering and mapping parameters to static values.
   alias SetName (NameIn : string) is Name.Set(NameIn); 

   . . . 
  end protected SemaphorePType ;</verbatim>

---++ General Comments

Essential for testbench utility composition.

Should the local variable be a shared one? I think there is no sharing model involved.<br />Moreover the access to the local variable is already protected by locks of the methods<br />of the hosting/enclosing protected type. So I think it's not necessary to use an access<br />modifier ('shared') in the variable declaration. This leaves us to the question: Does the<br />compiler need a hint that the local variable is a normal type or a protected one?

-- Main.PatrickLehmann - 2016-02-18
---++ Supporters

_Add your signature here to indicate your support for the proposal_

_-- Main.JimLewis - 2014-12-03_

-- Main.PatrickLehmann - 2016-02-18

-- Main.TorstenMeissner - 2016-05-25
Topic revision: r1 - 2020-02-17 - 15:34:36 - TWikiGuest
P1076