Calls in calls sequences should either generate an error or instantiate a subprogram

[stevevestal]

-- What is the OSATE interpretation of the AADL standard as to whether -- certain forms of subprogram calls inside subprogram calls sequences -- do or do not implicitly declare a subprogram subcomponent for the -- thread, subprogram, or other container of the subprogram calls sequence -- declaration? (This will probably make more sense if you glance at the -- example at the bottom first.)

-- Right now, OSATE does not implicitly declare such subprogram subcomponents. -- They do not appear in a generated instance file. Depending on how good -- your language lawyering department is, this might arguably be a permitted -- interpretation of the standard (see below). However, if OSATE lawyers -- are citing 5.2(C2), then shouldn't you issue an error to that effect -- during instantiation? If OSATE does so interpret and follow 5.2(4) -- below, then shouldn't you include subprogram subcomponents in the -- generated instance file for these?

-- The AADL standard says:

-- 5.2(4) Subprogram instances may be implied by a subprogram call reference -- to a subprogram type or implementation. In this case, a subprogram is -- implicitly instantiated within the containing process.

-- The choice of the term "process" is somewhat confusing. The standard -- says in paragraph (2) that call sequence declarations are only allowed in -- thread and subprogram declarations. However, that could mean such -- forms implicitly declare a subprogram subcomponent of the outer containing -- process. Or was this just a sloppy choice of word, they meant the -- thread or subprogram containing the calls sequence declaration?

-- Having said that, the standard also says:

-- 5.2(C2) A subprogram call may reference a subprogram classifier. A -- project may enforce a consistency rule that this reference be to a -- subprogram subcomponent declaration or requires subprogram access -- declaration. This ensures that a modeler consistently models subprogram -- calls the same way.

-- Does this mean that an implementor has permission to NOT follow -- rule 5.2(4) but instead only recognize a call within a subprogram -- call sequence that refers to an explicitly declared subprogram -- subcomponent?

-- Further on in the standard,

-- 5.2(18) The standard permits modeling of subprograms and subprogram calls -- without requiring the declaration of subprogram instances. In this case, -- subprogram calls may refer to subprogram classifiers and the source language -- processing system will determine the subprogram instance to be called. In -- the case of remote subprogram calls ....

-- This could reasonably be interpreted to apply to the special case of remote -- subprogram calls and thus not directly relevant to this discussion.

-- On a second topic, the grammar in the standard seems to allow property -- associations on subprogram calls within subprogram call sequence -- declarations,

-- subprogram_call ::= -- defining_call_identifier : subprogram called_subprogram -- [ { { subcomponent_call_property_association }+ } ] ;

-- I could not find any rules that imposed any restrictions on this.

package ImplicitCallsSubprograms
public

    subprogram SubProg          
    end SubProg;

    subprogram implementation SubProg.Imp       
    end SubProg.Imp;

    thread AThread
    end AThread;

    thread implementation AThread.WithCalls
        subcomponents
            sub: subprogram {Compute_Execution_Time => 1 ms .. 1 ms;};
            subT: subprogram SubProg;
            subTI: subprogram subProg.Imp;      
        calls
            main: {
                -- These cite already declared subprogram subcomponents,
                -- they do not create new subprogram subcomponents.
                s1: subprogram sub;
                s2: subprogram subT;
                s3: subprogram subTI;
                -- These use classifiers, which the standard says
                -- implicitly declare new subprogram subcomponents.
                -- Yet these do not appear in the OSATE instance file.
                -- Maybe the standard grants permission to not do that.
                s4: subprogram SubProg;
                s5: subprogram SubProg.Imp;
                -- OSATE says the following are erroneous, but they
                -- seem to be allowed in the grammar
                --s4a: subprogram SubProg {Compute_Execution_Time => 1 ms .. 1 ms;};
                --s1a: subprogram sub {Compute_Execution_Time => 1 ms .. 1 ms;};
            };
    end AThread.WithCalls;

end ImplicitCallsSubprograms;

[lwrage]

Instantiation currently ignores call sequences.

OSATE reports a error on the property association because Compute_Execution_Time applies to subprograms but not to subprogram calls. Only properties declared with subprogram call (or a superclass, or all) in the applies to clause are allowed there.

[lwrage]

@reteprelief Do you have any thoughts on this?

[reteprelief]

As to the properties: The standard document says that subprogram call an subprogram call sequence are sub types of subprogram (see Appendix C3). So compute execution time should be applicable to calls and sequences. In the Ecore model in Osate the calls and sequence are not a subclass of subprogram.

As to instantiation: The idea was that users would not have to model subprogram instances when defining call sequences, i.e., we allow reference to classifiers or subprogram access. In this case the assumption is that the underlying programming language system deals with instances of the subprogram code in libraries, whether in the process address space or as shared libraries. The memory requirements for that code would be included in the code size of the process or wherever the shared library is. Execution times for calls are picked up from the classifier.

In some cases people may want to explicitly model code instances, i.e., subprogram subcomponents. In this case the memory requirements are associated with the subprogram (or group for the library).

Execution times to be used for calls would come from the subprogram (if referenced and it has an explicit property) otherwise the classifier referenced by the subprogram.

I noticed that we do instantiate subprogram subcomponents but not calls and sequences. For manyanalyses call sequences are more interesting the subprogram instances.

In 5.2(4) we say "Subprogram instances may be implied by a subprogram call reference to a subprogram type or implementation.". Note the may, i.e., we do not have to instantiate the subprogram in order to instantiate the call, again the idea was that in those cases the subprogram would be in a library and we do not have to explicitly model the instance.

As to the text in 5.2(4) when writing this sentence I as making the assumption that processes own code - not threads. Thus, the statement about (enclosing) process.

[lwrage]

I don't see an OSATE bug that needs to be fixed, so I'm closing this issue.