⟦5b8551546⟧

TextFile


CA2 DECISIONS AND SEGMENTS
==========================================

SEGMENTS
--------

The simpest form of CA2 only measures Segments.  This can be done 
simply by putting a Bkpt at the head of each Segment.  If the Bkpt
is hit, the segment is covered and the Bkpt can be removed. 

Complexity 1
------------

Loop Statements (not while/for loops) have an odd problem in that no 
Bkpt can be created at the top of the loop.  So, if that Loop starts 
a Segment, then there is a problem setting the Bkpt.   This can be 
made worse with nested Loop Statements.

Solution
--------

For any FCP where a Bkpt is to be set at the Head, call
that FCP and have the target FCP own the Bkpt.  This is not really
necessary for anything but Loop Statements, but having a uniform
solution seems better.  (Also, Decisions make that Bkpt important
for some other constructs as well).

The requesting FCP will be registered with the target head FCP so
that the Bkpt can be propagated appropriately.   Must be careful
that the requesting FCP does not remove the Bkpt - that is up to
the owning FCP.


DECISIONS
---------

Unfortunately, it is not so simple to measure Decisions.  

Complexity 1 - No Segment
------------
There is no appropriate segment for some decisions - 
(ie if b then x end if).   So, the result of a decision requires
some measurement of the target action of an appropriate condition.
Note that this is not a problem for some constructs that have segments
for all decisions (if-else-endif,case-endcase).

Complexity 2  - Exceptions
------------
Not all decision points result in a decision.  If an exception occurs 
in  processing the condition, then no decision was reached.   This is
a very rare condition, but it must be handled. 

The R1000 does give a special Trap when an Exception is encountered.
The problem is knowing that this occurs in the condition evaluation.
When the exception occurs, there is no easy way to determine whether
the executing code was in that expression.  

Complexity 3 - For Loops
------------

For Loops dont have an obvious statement at each decision point. A
While Loop has a statement (the while condition) that is executed
each time thru the loop and can be used to trap the decision condition.
The entry to the For Loop does present a statement, but repeated loops
dont stop at any explicit statement.

It turns out that these loops end with a Loop_Increasing or Loop_Decreasing
instruction.   So, by trapping on that instruction at a low-level
interface, the CA should be able to stop on the condition.  Full verification
of that approach is still needed.   Otherwise, very complex logic is
required at the endpoint of each segment that can go back to the top of 
the loop (ie, the program must stop at the last statement of each of those
segments).   See note at end for discussion of how to find the For Loop end..


Complexity 4 - End of Subprograms
------------

If a Decision FCP ends a subprogram, the fallout condition is actually
to leave the Subp.  This means that there is no way to simply test for
a particular Bkpt on that fallout decision.   


ALTERNATIVE 1 - Counts
-------------

The first alternative is based on counting the times that the decision
point is reached vs the times that the "true" segment is reached.  Once
that count is different after the FCP is executed, then the "false" decision
has been taken.

Record a count at the point where the decision is reached.  One approach
is to always record counts and simply check at the time where the data is
written out.   This is a little complex since the count data would have
to be saved on a per Test Case basis.  

Another variation is to check the counts when the decision point is reached
again.  However, this may not happen, so some of the delayed resolution
is still required.  The advantage of checking immediately is to stop the 
counting.

Exceptions must be still be dealt with.  This requires that a flag is set
for the Task indicating that the condition is being visited.   For a 
FCP which is not at the end of the Subp, look for a stmt in the same depth.
Once that is encountered, then the Exc flag is cleared.    If an Exc occurs, 
and the handler is at the original depth or lower, then the count for the 
decision point is decremented.   Note that since subp calls can be made in 
the condition, this state and associated FCP info must be stored in a "stack"
for each task.   If the FCP is at the end of the FCP, check for leaving the
depth as well as for a next Stmt at the condition depth.

Pro:

a) Using the counts means that there is no need to determine the exact
target of the "false" decision - ie which FCP is the next possible one.

Con:

a) Using the counting and resolving at the end of the Test Case requires
leaving that Bkpt/Condition on thru the whole Test Case which can be 
an efficiency loss.   Checking the counts at the "decision point" removes
this cost. 

b) Having to determine the data at the end of the Test Case has some cost
in terms of saving a list or rewalking thru the appropriate FCPs.  Keeping
counts per TC is possible, but seems to have too many extra costs.


                                                  
ALTERNATIVE 2 - Stepping
-------------

The second alternative is based on finding the first Stmt that occurs
after the decision condition is encountered.   The Exc solution is basically
the same as for Alternative 1.   However, at the decision point, check the
next Stmt encountered (assuming no Exc).  That decision point should be 
one of a predetermined pair - either the true or false version.    

Determination of the "false" Bkpt is easy for cases where there is an immediate
following FCP.   For FCPs that are at the end of the Loop, the "false" Bkpt
will be the first statement (for a Loop Stmt or While Loop) or the "Loop_"
instruction for the For_Loop.   If the FCP ends a subp, then the "false" 
decision must be the Return from this depth.


Pro:

a) The problem of checking for counts at the end of the Test Case goes away.

b) This may map better to future steps forward with subconditions where a
detailed look at the condition evaluation will be required. 

c) Checking against specific Bkpts may actually be better than checking
for being on a Stmt boundary in the right depth.

Con:

a) At each Trap during decision condition evaluation, a check must be made
against the "true" and "false" Bkpts.  Alternative #1 simply requires that
something appropriate is hit.
               
NOTE: These solutions do require a list/stack of active decision condition
FCPs for a given task.  BUT those are only needed for a task that encounters
this situation, removing the issue of most package pseudo-tasks.

NOTE: - For Loops - 

The simplest method to find the For Loop ending decision instruction is to 
simply look for it whenever inside a For Loop.  However, that may be somewhat
costly.   Also, if an inner For Loop has been "turned off" since it is done,
how does the CA tell that the inner Loop End is not the right one.  That could
imply that nested For Loops must be left "on"....

Another approach is to find the instruction PC when processing the FCP For Loop.
This will require walking thru the Code Segment to find the appropriate 
instruction - however, that cost is only paid once, not each time the For Loop
is used.   Work is still required to determine how hard this PC locating is
to do
DataMuseum.dk

Rational R1000/400

⟦5b8551546⟧ TextFile

Derivation

TextFile
