Specifications

1 INTRODUCTION
1.1 Purpose and scope
Bound-T is a tool for computing bounds on the worst-case execution time and stack usage of
real-time programs; see references [1] and [2]. There are different versions of Bound-T for
different target processors. This Application Note supplements the Bound-T User Guide [1] and
Reference Manual [2] by giving additional information and advice on using Bound-T for one
particular target processor, the processor architecture known as the Renesas H8/300 [4]. This
processor was earlier known as the Hitachi H8/300.
The first goal of this document is to explain the additional command-line options and other
controls that are specific to the H8/300 version of Bound-T. The second goal is to explain the
sort of H8/300 code that Bound-T can or cannot analyse and so help you write analysable
programs.
Some information in Chapters 3 and 6 of this Application Note applies only when the target-
program executable is generated with specific compilers. These chapters discuss the GNU 'C'
cross-compiler [6] and the IAR Systems 'C' cross-compiler [7]. Other compilers may be
addressed in separate Application Notes.
This Application Note is applicable to various physical implementations (also known as
devices, derivates, models or chips) of the H8/300 core architecture. However, the memory
lay-out and timing parameters of the chip must be known to Bound-T.
1.2 Overview
The reader is assumed to be familiar with the general principles and usage of Bound-T, as
described in the Bound-T User Manual . The user manual also contains a glossary of terms,
many of which will be used in this Application Note.
So what's it all about?
In a nutshell, here is how Bound-T bounds the worst-case execution time (WCET) of a
subprogram: Starting from the executable, binary form of the program, Bound-T decodes the
machine instructions, constructs the control-flow graph, identifies loops, and (partially)
interprets the arithmetic operations to find the "loop-counter" variables that control the loops,
such as n in "for (n = 1; n < 20; n++) { ... }".
By comparing the initial value, step and limit value of the loop-counter variables, Bound-T
computes an upper bound on the number of times each loop is repeated. Combining the loop-
repetition bounds with the execution times of the subprogram's instructions gives an upper
bound on the worst-case execution time of the whole subprogram. If the subprogram calls
other subprograms, Bound-T constructs the call-graph and bounds the worst-case execution
time of the called subprograms in the same way.
When does it work?
This sort of "static program analysis" is in theory an unsolvable problem and cannot work for
all programs (like the well-known "halting problem"). It succeeds for programs that have a
suitable structure, for example programs in which all loops have counters with constant initial
and final values and a constant step. Moreover, since we are analysing low-level machine
coder rather than high-level source code, the nature of the instruction set and the specific
instructions used (or, usually, generated by the compiler) may help or hinder the analysis.
Bound-T for H8/300 Introduction 1