Typical Execution Marked 

Contexts in source publication

Context 1

... automatic timing model generation overcomes the need for additional measurements and access to hardware during software development, while the effort for developing a timing model is reduced. To facilitate the use of the timing model, we propose a 3-valued representation of the potential execution times. This directly presents the application’s ACET, BCET and WCET to the user. Thereby, the user is much better informed about the application’s potential behavior already in the development phase and additionally gets direct feedback on application changes. A mock-up of how this could look like is shown at the bottom of Figure 7. In addition to giving feedback to the user, the average-case execution time estimate can be significantly improved by only considering parts of the application which are included in a typical execution. Therefore, the user has to provide the required insights about the expected or typical program path—which often can be done due to the user’s experience and knowledge of the application. In combination with the previously described ACET estimates for recurring code sequences and structural program information, a more accurate approximation of the typical case can be achieved. The reason for this is that execution time outliers are less likely to impact the result of the average-case estimate. The standard way of simply averaging the executing time of observed program runs to get an ACET estimate would still include such outliers, but the proposed approach allows excluding such atypical executions. Finally, the 3-valued representation of the execution times still makes the worst case explicit to the user and thus, no information is lost compared to a standard WCET analysis. The example program from section 2.1 will be used to illustrate the application of user feedback in estimating execution times. If we assume that the programmer of the code shown in Figure 7 knows that conditional expression in the loop typically evaluates to true immediately, she can mark the respective code area as being part of the typical execution. This is illustrated in Figure 7 by shading the respective code area. A similar tagging functionality could be easily added to any code editor. While this is an artificial example, similar patterns can often be found in control applications, e.g., for initialization code. By automatically translating this information into constraints for the global bound calculation analysis step, it can be used to restrict the program paths through the CFG. Thus, the program path determined by the global analysis for the ACET step no longer considers the worst-case path, but the typical path. The resulting program path for the example is shown in Figure 8. The edges drawn as dotted lines and the frequency annotations next to them describe the typical path. Consequently, each of the basic blocks along this path is executed exactly once. Using this information and the execution time of each basic block, which is also annotated to the CFG in Figure 8, an ACET of 25 cycles can be derived. The respective ACET formula is shown in the lower portion of Figure 8. Even if there is only small ...

Context 2

... automatic timing model generation overcomes the need for additional measurements and access to hardware during software development, while the effort for developing a timing model is reduced. To facilitate the use of the timing model, we propose a 3-valued representation of the potential execution times. This directly presents the application’s ACET, BCET and WCET to the user. Thereby, the user is much better informed about the application’s potential behavior already in the development phase and additionally gets direct feedback on application changes. A mock-up of how this could look like is shown at the bottom of Figure 7. In addition to giving feedback to the user, the average-case execution time estimate can be significantly improved by only considering parts of the application which are included in a typical execution. Therefore, the user has to provide the required insights about the expected or typical program path—which often can be done due to the user’s experience and knowledge of the application. In combination with the previously described ACET estimates for recurring code sequences and structural program information, a more accurate approximation of the typical case can be achieved. The reason for this is that execution time outliers are less likely to impact the result of the average-case estimate. The standard way of simply averaging the executing time of observed program runs to get an ACET estimate would still include such outliers, but the proposed approach allows excluding such atypical executions. Finally, the 3-valued representation of the execution times still makes the worst case explicit to the user and thus, no information is lost compared to a standard WCET analysis. The example program from section 2.1 will be used to illustrate the application of user feedback in estimating execution times. If we assume that the programmer of the code shown in Figure 7 knows that conditional expression in the loop typically evaluates to true immediately, she can mark the respective code area as being part of the typical execution. This is illustrated in Figure 7 by shading the respective code area. A similar tagging functionality could be easily added to any code editor. While this is an artificial example, similar patterns can often be found in control applications, e.g., for initialization code. By automatically translating this information into constraints for the global bound calculation analysis step, it can be used to restrict the program paths through the CFG. Thus, the program path determined by the global analysis for the ACET step no longer considers the worst-case path, but the typical path. The resulting program path for the example is shown in Figure 8. The edges drawn as dotted lines and the frequency annotations next to them describe the typical path. Consequently, each of the basic blocks along this path is executed exactly once. Using this information and the execution time of each basic block, which is also annotated to the CFG in Figure 8, an ACET of 25 cycles can be derived. The respective ACET formula is shown in the lower portion of Figure 8. Even if there is only small ...

Context 3

... automatic timing model generation overcomes the need for additional measurements and access to hardware during software development, while the effort for developing a timing model is reduced. To facilitate the use of the timing model, we propose a 3-valued representation of the potential execution times. This directly presents the application’s ACET, BCET and WCET to the user. Thereby, the user is much better informed about the application’s potential behavior already in the development phase and additionally gets direct feedback on application changes. A mock-up of how this could look like is shown at the bottom of Figure 7. In addition to giving feedback to the user, the average-case execution time estimate can be significantly improved by only considering parts of the application which are included in a typical execution. Therefore, the user has to provide the required insights about the expected or typical program path—which often can be done due to the user’s experience and knowledge of the application. In combination with the previously described ACET estimates for recurring code sequences and structural program information, a more accurate approximation of the typical case can be achieved. The reason for this is that execution time outliers are less likely to impact the result of the average-case estimate. The standard way of simply averaging the executing time of observed program runs to get an ACET estimate would still include such outliers, but the proposed approach allows excluding such atypical executions. Finally, the 3-valued representation of the execution times still makes the worst case explicit to the user and thus, no information is lost compared to a standard WCET analysis. The example program from section 2.1 will be used to illustrate the application of user feedback in estimating execution times. If we assume that the programmer of the code shown in Figure 7 knows that conditional expression in the loop typically evaluates to true immediately, she can mark the respective code area as being part of the typical execution. This is illustrated in Figure 7 by shading the respective code area. A similar tagging functionality could be easily added to any code editor. While this is an artificial example, similar patterns can often be found in control applications, e.g., for initialization code. By automatically translating this information into constraints for the global bound calculation analysis step, it can be used to restrict the program paths through the CFG. Thus, the program path determined by the global analysis for the ACET step no longer considers the worst-case path, but the typical path. The resulting program path for the example is shown in Figure 8. The edges drawn as dotted lines and the frequency annotations next to them describe the typical path. Consequently, each of the basic blocks along this path is executed exactly once. Using this information and the execution time of each basic block, which is also annotated to the CFG in Figure 8, an ACET of 25 cycles can be derived. The respective ACET formula is shown in the lower portion of Figure 8. Even if there is only small ...

Context 4

... the average-case and the worst-case execution time of the basic blocks, considering information about the typical program path can still reduce the overestimation of static timing analysis. While existing WCET analysis tools already support similar path constraints, the underlying timing model is always a pure worst-case analysis. The combination of the ACET estimates and the user-provided information about the typical program path allows for characterizing the typical execution time of programs more accurately than with existing solutions. Thus, it goes beyond classical BCET and WCET analysis. Since the results of the WCET and BCET analysis are still represented, the information is still available to the user of the timing analysis. Adding average-case information allows to additionally reason about the load of a computer system by considering typical execution paths only. The proposed approach depends, however, on the user’s correct knowledge on the typical execution path. Thus, we are planning to case-study the quality of user input and the impact of wrong assumptions, e.g., mistakenly unmarked typical code areas or wrongly marked code areas, on calculated ACET estimates with real industrial applications and users. The 3-valued execution time estimation can be applied at different levels of granularity, e.g., complete applications, components, or individual source code lines. We envision an integration of this representation into the integrated development environment for the developers of control applications. This is illustrated in the lower portion of Figure 7. By integrating this representation into the application development environment, the contribution of individual program parts is directly presented to the application developer. Thereby the 3-valued representation makes the possible variation of execution times explicit to the developer. In addition, program parts with a high contribution to the execution time are highlighted directly if the 3-valued execution time estimate is represented at the level of basic blocks or individual code lines. To adapt the 3-valued execution time estimate, the developer can mark program areas as being not part of a typical execution. This will exclude the respective program parts from the average- case execution time estimate. Alternatively, the offending program parts can be optimized manually by the developer and the 3-valued estimate can instantly provide information about the impact of the code changes on the execution time. In the context of industrial control applications, code portions which belong to an atypical execution path can often be identified automatically. The result of a certain firmware function directly relates to whether the controller is in a typical state or not. For instance in most executions of a control application, the firmware function which checks whether the device just experienced a warm restart will return false . Thus, when the respective function is used in a conditional expression, this can be directly translated into a constraint for the average-case analysis. When performing a worst-case analysis, these constraints should of course not be used as they might lead to an underestimation of the WCET. Essentially, marking certain code areas as the typical execution path excludes alternative paths from the WCET analysis and thus approximates the expected behavior more accurately. Depending on the application for which the execution time is estimated, the user-provided information could also be used to tag code areas for other scenario-based analyses. This allows for a more accurate estimation of the execution time under certain preconditions. The proposed approach could therefore also be extended for analyzing the execution time of a program under specific operating conditions. This section presents preliminary results for the proposed timing model generation work flow. The prototyping was carried out using the machine code output facilities of ABB’s Compact Control Builder development tool targeting the ABB AC 800M controller family. The basic block and window-based hash computation described in Section 3.2 were applied to three real-world Compact Control Builder projects to evaluate the amount of code sharing across different applications. Each project contained multiple control applications which shared some code through common libraries. However, these libraries are always reused as source code, not as compiled machine code. Binary-level code sharing was analyzed by first calculating all possible digests for a fixed calculation technique for two of the three projects. All of the possible digests were stored in a database. Then all possible digests of the remaining project were computed and compared to the information stored in the database. The outcome of this experiment is shown in Table 1 for the basic block digest computation and window-based digest computation using a window size of 8 and 16 instructions. The size of each project is given in terms of instructions in the machine code after compilation. If certain modules were reused across different applications in the same project, the respective machine instructions were only counted once. The detection of recurring code patterns across the different projects could be executed in a few minutes on a standard laptop computer. Since the analysis tools is a very early prototype, no detailed performance measurements were conducted. The number of recurring code sequences was calculated by counting the number of hash digests a project has in common with the two remaining projects. So the numbers given in each line of the table show how much recurring code patterns where found in the respective project when the other projects where used as training data. Besides counting the number of recurring code sequences for the respective clone detection granularity, the second result column for each variant contains the percentage of machine instructions covered by these sequences. This value is calculated by dividing the number of machine instructions within a project which are included in recurring code sequences by the total number of instructions in the project. The rationale behind this estimation is that it determines the maximal achievable coverage if all recurring code sequences of the respective granularity would be part of the timing model. The instruction coverage is relevant since it is not only an indicator of how much code sharing between different projects could be detected, but also what amount of code was not covered by ...