source: Papers/fopara2013/fopara13.tex @ 3434

Last change on this file since 3434 was 3434, checked in by campbell, 6 years ago

Section 4.3 revised.

File size: 63.9 KB
12            bookmarks,bookmarksopen,bookmarksdepth=2]{hyperref}
31        {\setlength{\fboxsep}{5pt}
32                \setlength{\mylength}{\linewidth}%
33                \addtolength{\mylength}{-2\fboxsep}%
34                \addtolength{\mylength}{-2\fboxrule}%
35                \Sbox
36                \minipage{\mylength}%
37                        \setlength{\abovedisplayskip}{0pt}%
38                        \setlength{\belowdisplayskip}{0pt}%
39                }%
40                {\endminipage\endSbox
41                        \[\fbox{\TheSbox}\]}
[3327]43\title{Certified Complexity (CerCo)\thanks{The project CerCo acknowledges the
44financial support of the Future and Emerging Technologies (FET) programme within
45the Seventh Framework Programme for Research of the European Commission, under
46FET-Open grant number: 243881}}
[3335]49R.~M. Amadio$^{4}$ \and
[3335]51N.~Ayache$^{3,4}$ \and
[3335]53F.~Bobot$^{3,4}$ \and
[3333]55J.~P. Boender$^1$ \and
[3333]57B.~Campbell$^2$ \and
[3333]59I.~Garnier$^2$ \and
[3333]61A.~Madet$^4$ \and
[3333]63J.~McKinna$^2$ \and
[3333]65D.~P. Mulligan$^1$ \and
[3333]67M.~Piccolo$^1$ \and
[3333]69R.~Pollack$^2$ \and
[3335]71Y.~R\'egis-Gianas$^{3,4}$ \and
[3333]73C.~Sacerdoti Coen$^1$ \and
[3333]75I.~Stark$^2$ \and
[3327]78\institute{Dipartimento di Informatica - Scienza e Ingegneria, Universit\'a di
79Bologna \and
[3333]80LFCS, School of Informatics, University of Edinburgh
[3431]81\and INRIA (Team $\pi r^2$)
[3335]83Universit\`e Paris Diderot
[3419]92% Brian: I've changed "without loss of accuracy" because we discuss
93% important precision/complexity tradeoffs for advanced architectures
94% in the dependent labelling section.
[3320]96This paper provides an overview of the FET-Open Project CerCo
[3334]97(`Certified Complexity'). The project's main achievement is
[3419]98the development of a technique for analysing non-functional
99properties of programs (time, space) at the source level, with little or no loss of accuracy
[3430]100and with a small trusted code base. The main software component
[3335]101developed is a certified compiler producing cost annotations. The compiler
[3331]102translates source code to object code and produces an instrumented copy of the
[3334]103source code. This instrumentation exposes at
[3331]104the source level---and tracks precisely---the actual (non-asymptotic)
105computational cost of the input program. Untrusted invariant generators and trusted theorem provers
[3419]106can then be used to compute and certify the parametric execution time of the
110% ---------------------------------------------------------------------------- %
111% SECTION                                                                      %
112% ---------------------------------------------------------------------------- %
[3430]115%\paragraph{Problem statement.}
116Computer programs can be specified with both
[3327]117functional constraints (what a program must do) and non-functional constraints
[3430]118(what resources---time, space, etc.---the program may use).  In the current
[3327]119state of the art, functional properties are verified for high-level source code
120by combining user annotations (e.g. preconditions and invariants) with a
121multitude of automated analyses (invariant generators, type systems, abstract
[3334]122interpretation, theorem proving, and so on). By contrast, non-functional properties
[3327]123are generally checked on low-level object code, but also demand information
[3430]124about high-level functional behaviour that must somehow be reconstructed.
[3327]126This situation presents several problems: 1) it can be hard to infer this
[3334]127high-level structure in the presence of compiler optimisations; 2) techniques
128working on object code are not useful in early development, yet problems
[3327]129detected later are more expensive to tackle; 3) parametric cost analysis is very
130hard: how can we reflect a cost that depends on the execution state (e.g. the
131value of a register or a carry bit) to a cost that the user can understand
[3430]132looking at source code? 4) performing functional analysis on the object code
133makes it hard for the programmer to provide information, leading to less precision in
[3327]134the estimates.
[3339]136\paragraph{Vision and approach.} We want to reconcile functional and
[3334]137non-functional analyses: to share information and perform both at the same time
[3327]138on source code.
140What has previously prevented this approach is the lack of a uniform and precise
141cost model for high-level code: 1) each statement occurrence is compiled
[3334]142differently and optimisations may change control flow; 2) the cost of an object
[3327]143code instruction may depend on the runtime state of hardware components like
[3334]144pipelines and caches, all of which are not visible in the source code.
[3327]146To solve the issue, we envision a new generation of compilers able to keep track
147of program structure through compilation and optimisation, and to exploit that
148information to define a cost model for source code that is precise, non-uniform,
[3430]149and which accounts for runtime state. With such a source-level cost model we can
[3327]150reduce non-functional verification to the functional case and exploit the state
[3334]151of the art in automated high-level verification~\cite{survey}. The techniques
[3417]152currently used by the Worst Case Execution Time (WCET) community, which perform the analysis on object code,
153are still available but can now be coupled with an additional source-level
[3327]154analysis. Where the approach produces precise cost models too complex to reason
155about, safe approximations can be used to trade complexity with precision.
[3430]156Finally, source code analysis can be used during the early stages of development, when
[3327]157components have been specified but not implemented: source code modularity means
[3329]158that it is enough to specify the non-functional behaviour of unimplemented
[3432]161\paragraph{Contributions.} We have developed what we refer to as \emph{the labelling approach} \cite{labelling}, a
[3327]162technique to implement compilers that induce cost models on source programs by
163very lightweight tracking of code changes through compilation. We have studied
164how to formally prove the correctness of compilers implementing this technique.
165We have implemented such a compiler from C to object binaries for the 8051
[3430]166micro-controller, and verified it in an interactive theorem prover.
[3430]168To demonstrate source-level verification of costs we have implemented
169a Frama-C plugin \cite{framac} that invokes the compiler on a source
170program and uses this to generate invariants on the high-level source
171that correctly model low-level costs. The plugin certifies that the
172program respects these costs by calling automated theorem provers, a
173new and innovative technique in the field of cost analysis. Finally,
174we have conduct several case studies, including showing that the
175plugin can automatically compute and certify the exact reaction time
176of Lustre~\cite{lustre} data flow programs compiled into C.
178\section{Project context and approach}
[3327]179Formal methods for verification of functional properties of programs have
[3334]180now reached a level of maturity and automation that is facilitating a slow but
[3327]181increasing adoption in production environments. For safety critical code, it is
[3334]182becoming commonplace to combine rigorous software engineering methodologies and testing
183with static analysis, taking the strong points of each approach and mitigating
184their weaknesses. Of particular interest are open frameworks
[3327]185for the combination of different formal methods, where the programs can be
186progressively specified and are continuously enriched with new safety
187guarantees: every method contributes knowledge (e.g. new invariants) that
188becomes an assumption for later analysis.
[3327]190The scenario for the verification of non-functional properties (time spent,
[3430]191memory used, energy consumed) is bleaker.
192% and the future seems to be getting even worse.
193Most industries verify that real time systems meet their deadlines
[3334]194by simply performing many runs of the system and timing their execution,  computing the
[3327]195maximum time and adding an empirical safety margin, claiming the result to be a
196bound for the WCET of the program. Formal methods and software to statically
197analyse the WCET of programs exist, but they often produce bounds that are too
[3430]198pessimistic to be useful. Recent advancements in hardware architecture
199have been
[3327]200focused on the improvement of the average case performance, not the
[3334]201predictability of the worst case. Execution time is becoming increasingly
202dependent on execution history and the internal state of
203hardware components like pipelines and caches. Multi-core processors and non-uniform
204memory models are drastically reducing the possibility of performing
[3327]205static analysis in isolation, because programs are less and less time
[3334]206composable. Clock-precise hardware models are necessary for static analysis, and
[3430]207obtaining them is becoming harder due to the increased sophistication
[3334]208of hardware design.
[3430]210Despite the aforementioned problems, the need for reliable real time
211systems and programs is increasing, and there is increasing pressure
212from the research community towards the introduction of alternative
213hardware with more predictable behaviour, which would be more suitable
214for static analysis.  One example being investigated by the Proartis
215project~\cite{proartis} is to decouple execution time from execution
216history by introducing randomisation.
[3330]218In the CerCo project \cite{cerco} we do not try to address this problem, optimistically
[3430]219assuming that improvements in low-level timing analysis or architecture will make
220verification feasible in the longer term. The main objective of our work is
[3327]221instead to bring together static analysis of functional and non-functional
222properties, which, according to the current state of the art, are completely
223independent activities with limited exchange of information: while the
224functional properties are verified on the source code, the analysis of
225non-functional properties is entirely performed on the object code to exploit
[3334]226clock-precise hardware models.
[3422]228\subsection{Current object-code methods}
[3334]230Analysis currently takes place on object code for two main reasons.
[3422]231First, there cannot be a uniform, precise cost model for source
[3327]232code instructions (or even basic blocks). During compilation, high level
233instructions are torn apart and reassembled in context-specific ways so that
[3334]234identifying a fragment of object code and a single high level instruction is
[3329]235infeasible. Even the control flow of the object and source code can be very
[3334]236different as a result of optimisations, for example aggressive loop
237optimisations may completely transform source level loops. Despite the lack of a uniform, compilation- and
[3327]238program-independent cost model on the source language, the literature on the
[3334]239analysis of non-asymptotic execution time on high level languages that assumes
[3430]240such a model is growing and gaining momentum. However, unless we provide a
[3334]241replacement for such cost models, this literature's future practical impact looks
242to be minimal. Some hope has been provided by the EmBounded project \cite{embounded}, which
243compositionally compiles high-level code to a byte code that is executed by an
[3430]244interpreter with guarantees on the maximal execution time spent for each byte code
245instruction. This provides a uniform model at the expense of the model's
246precision (each cost is a pessimistic upper bound) and the performance of the
247executed code (because the byte code is interpreted compositionally instead of
[3334]248performing a fully non-compositional compilation).
[3327]250The second reason to perform the analysis on the object code is that bounding
251the worst case execution time of small code fragments in isolation (e.g. loop
252bodies) and then adding up the bounds yields very poor estimates because no
[3430]253knowledge of the hardware state on executing the fragment can be assumed. By
[3327]254analysing longer runs the bound obtained becomes more precise because the lack
[3430]255of information about the initial state has a relatively small impact.
[3430]257To calculate the cost of an execution, value and control flow analyses
258are required to bound the number of times each basic block is
259executed.  Current state
260of the art WCET technology such as AbsInt performs these analyses on the
261object code, where the logic of the program is harder to reconstruct
262and most information available at the source code level has been lost;
263see~\cite{stateart} for a survey. Imprecision in the analysis can lead to useless bounds. To
264augment precision, the tools ask the user to provide constraints on
265the object code control flow, usually in the form of bounds on the
266number of iterations of loops or linear inequalities on them. This
267requires the user to manually link the source and object code,
268translating his assumptions on the source code (which may be wrong) to
269object code constraints. The task is error prone and hard, especially
270in the presence of complex compiler optimisations.
272Traditional techniques for WCET that work on object code are also affected by
273another problem: they cannot be applied before the generation of the object
274code. Functional properties can be analysed in early development stages, while
275analysis of non-functional properties may come too late to avoid expensive
276changes to the program architecture.
[3327]280In CerCo we propose a radically new approach to the problem: we reject the idea
281of a uniform cost model and we propose that the compiler, which knows how the
282code is translated, must return the cost model for basic blocks of high level
283instructions. It must do so by keeping track of the control flow modifications
[3430]284to reverse them and by interfacing with processor timing analysis.
[3327]286By embracing compilation, instead of avoiding it like EmBounded did, a CerCo
[3430]287compiler can both produce efficient code and return costs that are
288as precise as the processor timing analysis can be. Moreover, our costs can be
289parametric: the cost of a block can depend on actual program data, on a
290summary of the execution history, or on an approximated representation of the
[3327]291hardware state. For example, loop optimizations may assign to a loop body a cost
292that is a function of the number of iterations performed. As another example,
293the cost of a block may be a function of the vector of stalled pipeline states,
294which can be exposed in the source code and updated at each basic block exit. It
[3334]295is parametricity that allows one to analyse small code fragments without losing
[3327]296precision: in the analysis of the code fragment we do not have to ignore the
[3334]297initial hardware state. On the contrary, we can assume that we know exactly which
298state (or mode, as the WCET literature calls it) we are in.
[3334]300The CerCo approach has the potential to dramatically improve the state of the
301art. By performing control and data flow analyses on the source code, the error
[3327]302prone translation of invariants is completely avoided. It is in fact performed
303by the compiler itself when it induces the cost model on the source language.
304Moreover, any available technique for the verification of functional properties
305can be immediately reused and multiple techniques can collaborate together to
306infer and certify cost invariants for the program. Parametric cost analysis
[3430]307becomes the default one, with non-parametric bounds used as a last resort when
[3334]308trading the complexity of the analysis with its precision. \emph{A priori}, no
[3430]309technique previously used in traditional WCET is lost: processor
310timing analyses can be used by the compiler on the object code, and the rest can be applied
[3334]311at the source code level.
[3422]312 Our approach can also work in the early
313stages of development by axiomatically attaching costs to unimplemented components.
[3327]316All software used to verify properties of programs must be as bug free as
[3430]317possible. The trusted code base for verification consists of the code that needs
[3327]318to be trusted to believe that the property holds. The trusted code base of
319state-of-the-art WCET tools is very large: one needs to trust the control flow
320analyser and the linear programming libraries it uses and also the formal models
321of the hardware. In CerCo we are moving the control flow analysis to the source
[3334]322code and we are introducing a non-standard compiler too. To reduce the trusted
[3327]323code base, we implemented a prototype and a static analyser in an interactive
[3430]324theorem prover, which was used to certify that the costs added to the source
325code are indeed those incurred by the hardware. Formal models of the
[3327]326hardware and of the high level source languages were also implemented in the
327interactive theorem prover. Control flow analysis on the source code has been
328obtained using invariant generators, tools to produce proof obligations from
329generated invariants and automatic theorem provers to verify the obligations. If
330the automatic provers are able to generate proof traces that can be
331independently checked, the only remaining component that enters the trusted code
332base is an off-the-shelf invariant generator which, in turn, can be proved
333correct using an interactive theorem prover. Therefore we achieve the double
[3417]334objective of allowing the use of more off-the-shelf components (e.g. provers and
[3334]335invariant generators) whilst reducing the trusted code base at the same time.
[3327]337%\paragraph{Summary of the CerCo objectives.} To summarize, the goal of CerCo is
338% to reconcile functional with non-functional analysis by performing them together
339% on the source code, sharing common knowledge about execution invariants. We want
340% to achieve the goal implementing a new generation of compilers that induce a
341% parametric, precise cost model for basic blocks on the source code. The compiler
342% should be certified using an interactive theorem prover to minimize the trusted
343% code base of the analysis. Once the cost model is induced, off-the-shelf tools
344% and techniques can be combined together to infer and prove parametric cost
345% bounds.
[3320]346%The long term benefits of the CerCo vision are expected to be:
347%1. the possibility to perform static analysis during early development stages
348%2.  parametric bounds made easier
[3327]349%3.  the application of off-the-shelf techniques currently unused for the
350% analysis of non-functional properties, like automated proving and type systems
351%4. simpler and safer interaction with the user, that is still asked for
352% knowledge, but on the source code, with the additional possibility of actually
353% verifying the provided knowledge
[3320]354%5. a reduced trusted code base
355%6. the increased accuracy of the bounds themselves.
[3327]357%The long term success of the project is hindered by the increased complexity of
[3329]358% the static prediction of the non-functional behaviour of modern hardware. In the
[3327]359% time frame of the European contribution we have focused on the general
360% methodology and on the difficulties related to the development and certification
361% of a cost model inducing compiler.
[3334]363\section{The typical CerCo workflow}
[3420]368char a[] = {3, 2, 7, 14};
369char threshold = 4;
[3420]371int count(char *p, int len) {
[3311]372  char j;
373  int found = 0;
[3420]374  for (j=0; j < len; j++) {
375    if (*p <= threshold)
376      found++;
[3311]377    p++;
[3420]378    }
[3311]379  return found;
382int main() {
383  return count(a,4);
[3313]387%  $\vcenter{\includegraphics[width=7.5cm]{interaction_diagram.pdf}}$
389    baseline={([yshift=-.5ex]current bounding box)},
390    element/.style={draw, text width=1.6cm, on chain, text badly centered},
391    >=stealth
392    ]
393{[start chain=going below, node distance=.5cm]
394\node [element] (cerco) {CerCo\\compiler};
395\node [element] (cost)  {CerCo\\cost plugin};
396{[densely dashed]
397\node [element] (ded)   {Deductive\\platform};
398\node [element] (check) {Proof\\checker};
401\coordinate [left=3.5cm of cerco] (left);
402{[every node/.style={above, text width=3.5cm, text badly centered,
403                     font=\scriptsize}]
404\draw [<-] ([yshift=-1ex]cerco.north west) coordinate (t) --
405    node {C source}
406    (t-|left);
407\draw [->] (cerco) -- (cost);
408\draw [->] ([yshift=1ex]cerco.south west) coordinate (t) --
[3420]409    node {C source+\color{red}{cost annotations}}
[3313]410    (t-|left) coordinate (cerco out);
411\draw [->] ([yshift=1ex]cost.south west) coordinate (t) --
[3420]412    node {C source+\color{red}{cost annotations}\\+\color{blue}{synthesized assertions}}
[3313]413    (t-|left) coordinate (out);
414{[densely dashed]
415\draw [<-] ([yshift=-1ex]ded.north west) coordinate (t) --
[3420]416    node {C source+\color{red}{cost annotations}\\+\color{blue}{complexity assertions}}
[3313]417    (t-|left) coordinate (ded in) .. controls +(-.5, 0) and +(-.5, 0) .. (out);
418\draw [->] ([yshift=1ex]ded.south west) coordinate (t) --
419    node {complexity obligations}
420    (t-|left) coordinate (out);
421\draw [<-] ([yshift=-1ex]check.north west) coordinate (t) --
422    node {complexity proof}
423    (t-|left) .. controls +(-.5, 0) and +(-.5, 0) .. (out);
[3327]424\draw [dash phase=2.5pt] (cerco out) .. controls +(-1, 0) and +(-1, 0) ..
425    (ded in);
427%% user:
428% head
429\draw (current bounding box.west) ++(-.2,.5)
430    circle (.2) ++(0,-.2) -- ++(0,-.1) coordinate (t);
431% arms
432\draw (t) -- +(-.3,-.2);
433\draw (t) -- +(.3,-.2);
434% body
435\draw (t) -- ++(0,-.4) coordinate (t);
436% legs
437\draw (t) -- +(-.2,-.6);
438\draw (t) -- +(.2,-.6);
[3320]441\caption{On the left: code to count the array's elements
[3420]442 that are less than or equal to the threshold. On the right: CerCo's interaction
[3313]443 diagram. CerCo's components are drawn solid.}
[3427]446We illustrate the workflow we envisage (on the right
447of~\autoref{test1}) on an example program (on the left
448of~\autoref{test1}).  The user writes the program and feeds it to the
449CerCo compiler, which outputs an instrumented version of the same
450program that updates global variables that record the elapsed
451execution time and the stack space usage.  The red lines in
452\autoref{itest1} introducing variables, functions and function calls
[3430]453starting with \lstinline'__cost' and \lstinline'__stack' are the instrumentation introduced by the
454compiler.  For example, the two calls at the start of
455\lstinline'count' say that 4 bytes of stack are required, and that it
456takes 111 cycles to reach the next cost annotation (in the loop body).
[3432]457The compiler measures these on the labelled object code that it generates.
[3427]459 The annotated program can then be enriched with complexity
460assertions in the style of Hoare logic, that are passed to a deductive
461platform (in our case Frama-C). We provide as a Frama-C cost plugin a
[3430]462simple automatic synthesiser for complexity assertions which can
463be overridden by the user to increase or decrease accuracy.  These are the blue
[3431]464comments starting with \lstinline'/*@' in \autoref{itest1}, written in
465Frama-C's specification language, ACSL.  From the
[3427]466assertions, a general purpose deductive platform produces proof
467obligations which in turn can be closed by automatic or interactive
468provers, ending in a proof certificate.
[3420]470% NB: if you try this example with the live CD you should increase the timeout
472Twelve proof obligations are generated from~\autoref{itest1} (to prove
473that the loop invariant holds after one execution if it holds before,
474to prove that the whole program execution takes at most 1358 cycles,
475etc.).  Note that the synthesised time bound for \lstinline'count',
[3430]476$178+214*(1+\text{\lstinline'len'})$ cycles, is parametric in the length of
[3420]477the array. The CVC3 prover
478closes all obligations within half a minute on routine commodity
479hardware.  A simpler non-parametric version can be solved in a few
484        moredelim=[is][\color{blue}]{$}{$},
[3429]485        moredelim=[is][\color{red}]{|}{|},
486        lineskip=-2pt}
[3420]489|int __cost = 33, __stack = 5, __stack_max = 5;|
490|void __cost_incr(int incr) { __cost += incr; }|
[3310]491|void __stack_incr(int incr) {
[3420]492  __stack += incr;
[3310]493  __stack_max = __stack_max < __stack ? __stack : __stack_max;
[3420]496char a[4] = {3, 2, 7, 14};  char threshold = 4;
[3420]498/*@ behavior stack_cost:
499      ensures __stack_max <= __max(\old(__stack_max), 4+\old(__stack));
[3310]500      ensures __stack == \old(__stack);
[3420]501    behavior time_cost:
502      ensures __cost <= \old(__cost)+(178+214*__max(1+\at(len,Pre), 0));
[3430]504int count(char *p, int len) {
[3420]505  char j;  int found = 0;
506  |__stack_incr(4);  __cost_incr(111);|
[3310]507  $__l: /* internal */$
508  /*@ for time_cost: loop invariant
[3420]509        __cost <= \at(__cost,__l)+
510                  214*(__max(\at((len-j)+1,__l), 0)-__max(1+(len-j), 0));
[3310]511      for stack_cost: loop invariant
512        __stack_max == \at(__stack_max,__l);
513      for stack_cost: loop invariant
514        __stack == \at(__stack,__l);
[3420]515      loop variant len-j;
516  */
517  for (j = 0; j < len; j++) {
518    |__cost_incr(78);|
519    if (*p <= threshold) { |__cost_incr(136);| found ++; }
520    else { |__cost_incr(114);| }
521    p ++;
[3310]522  }
[3420]523  |__cost_incr(67);  __stack_incr(-4);|
[3310]524  return found;
527/*@ behavior stack_cost:
528      ensures __stack_max <= __max(\old(__stack_max), 6+\old(__stack));
529      ensures __stack == \old(__stack);
530    behavior time_cost:
531      ensures __cost <= \old(__cost)+1358;
533int main(void) {
534  int t;
535  |__stack_incr(2);  __cost_incr(110);|
536  t = count(a,4);
537  |__stack_incr(-2);|
538  return t;
[3317]541\caption{The instrumented version of the program in \autoref{test1},
[3320]542 with instrumentation added by the CerCo compiler in red and cost invariants
543 added by the CerCo Frama-C plugin in blue. The \texttt{\_\_cost},
[3327]544 \texttt{\_\_stack} and \texttt{\_\_stack\_max} variables hold the elapsed time
[3329]545in clock cycles and the current and maximum stack usage. Their initial values
546hold the clock cycles spent in initialising the global data before calling
[3320]547\texttt{main} and the space required by global data (and thus unavailable for
548the stack).
[3339]552\section{Main scientific and technical results}
[3432]553First we describe the basic labelling approach and our compiler
[3425]554implementations that use it.  This is suitable for basic architectures
[3432]555with simple cost models.  Then we will discuss the dependent labelling
[3425]556extension which is suitable for more advanced processor architectures
557and compiler optimisations.  At the end of this section we will
558demonstrate automated high level reasoning about the source level
559costs provided by the compilers.
[3432]561% \emph{Dependent labelling~\cite{?}.} The basic labelling approach assumes a
[3328]562% bijective mapping between object code and source code O(1) blocks (called basic
563% blocks). This assumption is violated by many program optimizations (e.g. loop
564% peeling and loop unrolling). It also assumes the cost model computed on the
565% object code to be non parametric: every block must be assigned a cost that does
566% not depend on the state. This assumption is violated by stateful hardware like
[3432]567% pipelines, caches, branch prediction units. The dependent labelling approach is
568% an extension of the basic labelling approach that allows to handle parametric
[3328]569% cost models. We showed how the method allows to deal with loop optimizations and
570% pipelines, and we speculated about its applications to caches.
572% \emph{Techniques to exploit the induced cost model.} Every technique used for
573% the analysis of functional properties of programs can be adapted to analyse the
574% non-functional properties of the source code instrumented by compilers that
[3432]575% implement the labelling approach. In order to gain confidence in this claim, we
[3328]576% showed how to implement a cost invariant generator combining abstract
577% interpretation with separation logic ideas \cite{separation}. We integrated
578% everything in the Frama-C modular architecture, in order to compute proof
579% obligations from functional and cost invariants and to use automatic theorem
580% provers on them. This is an example of a new technique that is not currently
581% exploited in WCET analysis. It also shows how precise functional invariants
582% benefits the non-functional analysis too. Finally, we show how to fully
583% automatically analyse the reaction time of Lustre nodes that are first compiled
584% to C using a standard Lustre compiler and then processed by a C compiler that
[3432]585% implements the labelling approach.
587% \emph{The CerCo compiler.} This is a compiler from a large subset of the C
588% program to 8051/8052 object code,
[3432]589% integrating the labelling approach and a static analyser for 8051 executables.
[3328]590% The latter can be implemented easily and does not require dependent costs
591% because the 8051 microprocessor is a very simple one, with constant-cost
592% instruction. It was chosen to separate the issue of exact propagation of the
593% cost model from the orthogonal problem of the static analysis of object code
594% that may require approximations or dependent costs. The compiler comes in
595% several versions: some are prototypes implemented directly in OCaml, and they
[3432]596% implement both the basic and dependent labelling approaches; the final version
[3328]597% is extracted from a Matita certification and at the moment implements only the
598% basic approach.
[3432]600\subsection{The (basic) labelling approach}
601The labelling approach is the foundational insight that underlies all the developments in CerCo.
[3336]602It allows the tracking of the evolution of
603basic blocks during the compilation process in order to propagate the cost model from the
604object code to the source code without losing precision in the process.
[3328]605\paragraph{Problem statement.} Given a source program $P$, we want to obtain an
[3327]606instrumented source program $P'$,  written in the same programming language, and
607the object code $O$ such that: 1) $P'$ is obtained by inserting into $P$ some
608additional instructions to update global cost information like the amount of
609time spent during execution or the maximal stack space required; 2) $P$ and $P'$ 
[3329]610must have the same functional behaviour, i.e.\ they must produce that same output
[3327]611and intermediate observables; 3) $P$ and $O$ must have the same functional
[3329]612behaviour; 4) after execution and in interesting points during execution, the
[3327]613cost information computed by $P'$ must be an upper bound of the one spent by $O$ 
[3433]614to perform the corresponding operations (\emph{soundness} property); 5) the difference
[3327]615between the costs computed by $P'$ and the execution costs of $O$ must be
[3433]616bounded by a program-dependent constant (\emph{precision} property).
[3432]618\paragraph{The labelling software components.} We solve the problem in four
619stages \cite{labelling}, implemented by four software components that are used
[3327]620in sequence.
[3327]622The first component labels the source program $P$ by injecting label emission
[3328]623statements in appropriate positions to mark the beginning of basic blocks.
[3433]624These are the positions where the cost instrumentation will appear in the final output.
[3328]625% The
[3432]626% set of labels with their positions is called labelling.
[3328]627The syntax and semantics
[3327]628of the source programming language is augmented with label emission statements.
[3328]629The statement ``EMIT $\ell$'' behaves like a NOP instruction that does not affect the
630program state or control flow, but its execution is observable.
631% Therefore the observables of a run of a program becomes a stream
632% of label emissions: $\ell_1,\ldots,\ell_n$, called the program trace. We clarify the conditions
[3432]633% that the labelling must respect later.
[3433]634For the example in Section~\ref{sec:workflow} this is just the original C code
635with ``EMIT'' instructions added at every point a \lstinline'__cost_incr' call
636appears in the final code.
[3432]638The second component is a labelling preserving compiler. It can be obtained from
[3327]639an existing compiler by adding label emission statements to every intermediate
640language and by propagating label emission statements during compilation. The
[3329]641compiler is correct if it preserves both the functional behaviour of the program
[3433]642and the traces of observables, including the labels `emitted'.
[3328]643% We may also ask that the function that erases the cost
644% emission statements commute with compilation. This optional property grants that
[3432]645% the labelling does not interfere with the original compiler behaviour. A further
[3328]646% set of requirements will be added later.
[3433]648The third component analyses the labelled
649object code to compute the scope of each of its label emission statements,
650i.e.\ the instructions that may be executed after the statement and before
651a new label emission is encountered, and then computes the maximum cost of
652each.  Note that we only have enough information at this point to compute
653the cost of loop-free portions of code.  We will consider how to ensure that
654every loop is broken by a cost label shortly.
655%It is a tree and not a sequence because the scope
656%may contain a branching statement. In order to grant that such a finite tree
657%exists, the object code must not contain any loop that is not broken by a label
658%emission statement. This is the first requirement of a sound labelling. The
659%analyser fails if the labelling is unsound. For each scope, the analyser
660%computes an upper bound of the execution time required by the scope, using the
661%maximum of the costs of the two branches in case of a conditional statement.
662%Finally, the analyser computes the cost of a label by taking the maximum of the
663%costs of the scopes of every statement that emits that label.
[3433]665The fourth and final component replaces the labels in the labelled
666version of the source code produced at the start with the costs
667computed for each label's scope.  This yields the instrumented source
668code.  For the example, this is the code in \autoref{itest1}, except
669for the specifications in comments, which we consider in
[3433]672\paragraph{Correctness.} Requirements 1 and 2 hold because of the
673non-invasive labelling procedure.  Requirement 3 can be satisfied by
674implementing compilation correctly.  It is obvious that the value of
675the global cost variable of the instrumented source code is always
676equal to the sum of the costs of the labels emitted by the
677corresponding labelled code. Moreover, because the compiler preserves
678all traces, the sum of the costs of the labels emitted in the source
679and target labelled code are the same. Therefore, to satisfy the
680soundness requirement, we need to ensure that the time taken to
681execute the object code is equal to the sum of the costs of the labels
682emitted by the object code. We collect all the necessary conditions
683for this to happen in the definition of a \emph{sound} labelling: a)
684all loops must be broken by a cost emission statement; b) all program
685instructions must be in the scope of some cost emission statement.
686This ensures that every label's scope is a tree of instructions, with
687the cost being the most expensive path. To satisfy also the precision
688requirement, we must make the scopes flat sequences of instructions.
689We require a \emph{precise} labelling where every label is emitted at
690most once and both branches of each conditional jump start with a label
[3327]691emission statement.
[3432]693The correctness and precision of the labelling approach only rely on the
694correctness and precision of the object code labelling. The simplest
[3433]695way to achieve that is to impose correctness and precision
696requirements on the source code labelling produced at the start, and
697to demand that the compiler to preserve these
[3327]698properties too. The latter requirement imposes serious limitations on the
699compilation strategy and optimizations: the compiler may not duplicate any code
700that contains label emission statements, like loop bodies. Therefore several
[3336]701loop optimisations like peeling or unrolling are prevented. Moreover, precision
[3432]702of the object code labelling is not sufficient \emph{per se} to obtain global
[3417]703precision: we implicitly assumed that a precise constant cost can be assigned
704to every instruction. This is not possible in
[3336]705the presence of stateful hardware whose state influences the cost of operations,
[3425]706like pipelines and caches. In Section~\ref{lab:deplabel} we will see an extension of the
[3433]707basic labelling approach which tackles these problems.
[3425]709In CerCo we have developed several cost preserving compilers based on
[3432]710the labelling approach. Excluding an initial certified compiler for a
[3425]711`while' language, all remaining compilers target realistic source
712languages---a pure higher order functional language and a large subset
713of C with pointers, gotos and all data structures---and real world
714target processors---MIPS and the Intel 8051/8052 processor
715family. Moreover, they achieve a level of optimisation that ranges
716from moderate (comparable to GCC level 1) to intermediate (including
717loop peeling and unrolling, hoisting and late constant propagation).
718We describe the C compilers in detail in the following section.
[3425]720Two compilation chains were implemented for a purely functional
[3432]721higher-order language~\cite{labelling2}. The two main changes required
[3425]722to deal with functional languages are: 1) because global variables and
723updates are not available, the instrumentation phase produces monadic
724code to `update' the global costs; 2) the requirements for a sound and
[3432]725precise labelling of the source code must be changed when the
[3425]726compilation is based on CPS translations.  In particular, we need to
727introduce labels emitted before a statement is executed and also
728labels emitted after a statement is executed. The latter capture code
729that is inserted by the CPS translation and that would escape all
730label scopes.
[3417]732% Brian: one of the reviewers pointed out that standard Prolog implementations
733% do have some global state that apparently survives backtracking and might be
734% used.  As we haven't experimented with this, I think it's best to elide it
735% entirely.
[3417]737% Phases 1, 2 and 3 can be applied as well to logic languages (e.g. Prolog).
738% However, the instrumentation phase cannot: in standard Prolog there is no notion
739% of (global) variable whose state is not retracted during backtracking.
740% Therefore, the cost of executing computations that are later backtracked would
741% not be correctly counted in. Any extension of logic languages with
[3432]742% non-backtrackable state could support our labelling approach.
[3425]744\subsection{The CerCo C compilers}
745We implemented two C compilers, one implemented directly in OCaml and
746the other implemented in the interactive theorem prover
747Matita~\cite{matita}.  The first acted as a prototype for the second,
748but also supported MIPS and acted as a testbed for more advanced
[3432]749features such as the dependent labelling approach
[3425]750in Section~\ref{lab:deplabel}.
752The second C compiler is the \emph{Trusted CerCo Compiler}, whose cost
[3433]753predictions are formally verified. The executable code
754is OCaml code extracted from the Matita implementation. The Trusted
755CerCo Compiler only targets
756the C language and the 8051/8052 family, and does not yet implement any
757advanced optimisations. Its user interface, however, is the same as the
758other version for interoperability. In
759particular, the Frama-C CerCo plugin descibed in
760Section~\ref{sec:exploit} can work without recompilation
[3425]761with both of our C compilers.
763The 8051/8052 microprocessor is a very simple one, with constant-cost
764instructions. It was chosen to separate the issue of exact propagation of the
[3433]765cost model from the orthogonal problem of low-level timing analysis of object code
766that may require approximation or dependent costs.
768The (trusted) CerCo compiler implements the following optimisations: cast
769simplification, constant propagation in expressions, liveness analysis driven
770spilling of registers, dead code elimination, branch displacement, and tunneling.
771The two latter optimisations are performed by our optimising assembler
772\cite{correctness}. The back-end of the compiler works on three address
773instructions, preferred to static single assignment code for the simplicity of
774the formal certification.
776The CerCo compiler is loosely based on the CompCert compiler \cite{compcert}, a
777recently developed certified compiler from C to the PowerPC, ARM and x86
778microprocessors. In contrast to CompCert, both the CerCo code and its
779certification are fully open source. Some data structures and language definitions for
780the front-end are directly taken from CompCert, while the back-end is a redesign
781of a compiler from Pascal to MIPS used by Fran\c{c}ois Pottier for a course at the
782Ecole Polytechnique.
784The main differences in the CerCo compiler are:
786\item All the intermediate languages include label emitting instructions to
[3432]787implement the labelling approach, and the compiler preserves execution traces.
[3433]788\item Instead of targeting an assembly language with additional
789macro-instructions which are expanded before assembly, we directly
790produce object code in order to perform the timing analysis, using
791an integrated optimising assembler.
[3425]792\item In order to avoid the additional work of implementing a linker
793 and a loader, we do not support separate
794compilation and external calls. Adding them is orthogonal
[3432]795to the labelling approach and should not introduce extra problems.
[3425]796\item We target an 8-bit processor, in contrast to CompCert's 32-bit targets. This requires
797many changes and more compiler code, but it is not fundamentally more
798complex. The proof of correctness, however, becomes much harder.
[3430]799\item We target a microprocessor that has a non-uniform memory model, which is
[3425]800still often the case for microprocessors used in embedded systems and that is
801becoming common again in multi-core processors. Therefore the compiler has to
802keep track of data and it must move data between memory regions in the proper
[3433]803way. Moreover the size of pointers to different regions is not uniform. %An
804%additional difficulty was that the space available for the stack in internal
805%memory in the 8051 is tiny, allowing only a minor number of nested calls. To
806%support full recursion in order to test the CerCo tools also on recursive
807%programs, the compiler implements a stack in external memory.
810\subsection{Formal certification of the CerCo compiler}
811We have formally
812certified in the Matita interactive proof assistant that the cost models induced on the source code by the
813Trusted CerCo Compiler correctly and precisely
814predict the object code behaviour. There are two cost models, one for execution
815time and one for stack space consumption. We show the correctness of the prediction
[3434]816only for those programs that do not exhaust the available stack space, a
[3425]817property that---thanks to the stack cost model---we can statically analyse on the
[3434]818source code in sharp contrast to other certified compilers.  Other projects have
[3425]819already certified the preservation of functional semantics in similar compilers,
[3434]820so we have not attempted to directly repeat that work and assume
821functional correctness for most passes. In order to complete the
822proof for non-functional properties, we have introduced a new,
823structured, form of execution traces, with the
824related notions for forward similarity and the intensional
[3425]825consequences of forward similarity. We have also introduced a unified
826representation for back-end intermediate languages that was exploited to provide
827a uniform proof of forward similarity.
829The details on the proof techniques employed
[3434]831the proof sketch can be found in the CerCo deliverables and papers.
[3425]832In this section we will only hint at the correctness statement, which turned
[3434]833out to be more complex than expected.
[3434]835\paragraph{The correctness statement.}
[3425]836Real time programs are often reactive programs that loop forever responding to
837events (inputs) by performing some computation followed by some action (output)
[3434]838and continuing as before. For these programs the overall execution
839time does not make sense. The same is true for reactive programs that spend an
840unpredictable amount of time in I/O. Instead, what is interesting is the reaction time ---
841 the time spent between I/O events. Moreover, we are interested in
[3428]842predicting and ruling out crashes due to running out of space on certain
[3434]844Therefore we need a statement that talks about sub-runs of a
845program. A natural candidate is that the time predicted on the source
[3425]846code and spent on the object code by two corresponding sub-runs are the same.
[3434]847To make this statement formal we must identify the
[3425]848corresponding sub-runs and how to single out those that are meaningful.
[3434]849We introduce the notion of a \emph{measurable} sub-run of a run
850which does not exhaust the available stack before or during the
851sub-run, the number of function calls and returns
852in the sub-run is the same, the sub-run does not perform any I/O, and the sub-run
[3425]853starts with a label emission statement and ends with a return or another label
[3434]854emission statement. The stack usage is bounded using the stack usage model
[3425]855that is computed by the compiler.
857The statement that we formally proved is: for each C run with a measurable
[3434]858sub-run, there exists an object code run with a sub-run, with the same
859execution trace for both the prefix of the run and the sub-run itself,
860 and where the time spent by the
861object code in the sub-run is the same as the time predicted on the source code
[3425]862using the time cost model generated by the compiler.
[3425]865We briefly discuss the constraints for measurability. Not exhausting the stack
[3434]866space is necessary for a run to be meaningful, because the source semantics
867has no notion of running out of memory. Balancing
[3432]868function calls and returns is a requirement for precision: the labelling approach
[3434]869allows the scope of a label to extend after function calls to
870minimize the number of labels. (The scope excludes the called
871function's execution.) If the number of
[3425]872calls/returns is unbalanced, it means that there is a call we have not returned
873to that could be followed by additional instructions whose cost has already been
[3434]874taken in account.  The last condition on the start and end points of
875a run is also required to make the bound precise.  With these
876restrictions and the 8051's simple timing model we obtain \emph{exact}
877predictions.  If we relax these conditions then we obtain a corollary
878with an upper bound on the cost.
879Finally, I/O operations can be performed in the prefix of the run, but not in the
[3425]880measurable sub-run. Therefore we prove that we can predict reaction times, but
881not I/O times, as desired.
[3432]883\subsection{Dependent labelling}
[3432]885The core idea of the basic labelling approach is to establish a tight connection
[3327]886between basic blocks executed in the source and target languages. Once the
887connection is established, any cost model computed on the object code can be
888transferred to the source code, without affecting the code of the compiler or
889its proof. In particular, it is immediate that we can also transport cost models
890that associate to each label functions from hardware state to natural numbers.
891However, a problem arises during the instrumentation phase that replaces cost
892emission statements with increments of global cost variables. The global cost
893variable must be incremented with the result of applying the function associated
894to the label to the hardware state at the time of execution of the block.
[3328]895The hardware state comprises both the functional state that affects the
896computation (the value of the registers and memory) and the non-functional
[3424]897state that does not (the pipeline and cache contents, for example). The former is
[3327]898in correspondence with the source code state, but reconstructing the
899correspondence may be hard and lifting the cost model to work on the source code
[3336]900state is likely to produce cost expressions that are too complex to understand and reason about.
[3424]901Fortunately, in all modern architectures the cost of executing single
[3328]902instructions is either independent of the functional state or the jitter---the
903difference between the worst and best case execution times---is small enough
[3424]904to be bounded without losing too much precision. Therefore we only consider
905dependencies on the `non-functional' parts of the state.
[3428]907The non-functional state is not directly related to the high level
908state and does not influence the functional properties. What can be
909done is to expose key aspects of the non-functional state in the
910source code. We present here the basic intuition in a simplified form:
911the technical details that allow us to handle the general case are
912more complex and can be found in~\cite{paolo}. We add to the source
913code an additional global variable that represents the non-functional
914state and another one that remembers the last few labels emitted. The
915state variable must be updated at every label emission statement,
916using an update function which is computed during static analysis
917too. The update function associates to each label a function from the
918recently emitted labels and old state to the new state. It is computed
919by composing the semantics of every instruction in a basic block and
920restricting it to the non-functional part of the state.
[3327]922Not all the details of the non-functional state needs to be exposed, and the
923technique works better when the part of state that is required can be summarized
924in a simple data structure. For example, to handle simple but realistic
925pipelines it is sufficient to remember a short integer that encodes the position
[3417]926of bubbles (stuck instructions) in the pipeline. In any case, it is not necessary
927for the user to understand the meaning of the state to reason over the properties
928of the
929program. Moreover, at any moment the user, or the invariant generator tools that
930analyse the instrumented source code produced by the compiler, can decide to
[3428]931trade precision of the analysis for simplicity by approximating the
932cost with safe bounds that do not depend on the processor state. Interestingly, the functional analysis of
[3424]933the code could determine which blocks are executed more frequently in order to
934use more aggressive approximations for the ones that are executed least.
[3432]936Dependent labelling can also be applied to allow the compiler to duplicate
[3336]937blocks that contain labels (e.g. in loop optimisations)~\cite{paolo}. The effect is to assign
[3327]938a different cost to the different occurrences of a duplicated label. For
939example, loop peeling turns a loop into the concatenation of a copy of the loop
[3424]940body for the first iteration and the conditional execution of the
941loop for successive iterations. Further optimisations will compile the two
942copies of the loop differently, with the first body usually
[3327]943taking more time.
[3417]945By introducing a variable that keeps track of the iteration number, we can
[3327]946associate to the label a cost that is a function of the iteration number. The
947same technique works for loop unrolling without modifications: the function will
948assign a cost to the even iterations and another cost to the odd ones. The
[3336]949actual work to be done consists of introducing within the source code, and for each
950loop, a variable that counts the number of iterations. The loop optimisation code
[3424]951that duplicate the loop bodies must also modify the code to correctly propagate
[3327]952the update of the iteration numbers. The technical details are more complex and
953can be found in the CerCo reports and publications. The implementation, however,
[3425]954is quite simple (and forms part of our OCaml version of the compiler)
955and the changes to a loop optimising compiler are minimal.
[3328]957\subsection{Techniques to exploit the induced cost model}
[3425]959We now turn our attention to synthesising high-level costs, such as
960the execution time of a whole program.  We consider as our starting point source level costs
[3432]961provided by basic labelling, in other words annotations
[3425]962on the source code which are constants that provide a sound and sufficiently
[3327]963precise upper bound on the cost of executing the blocks after compilation to
964object code.
[3327]966The principle that we have followed in designing the cost synthesis tools is
967that the synthetic bounds should be expressed and proved within a general
968purpose tool built to reason on the source code. In particular, we rely on the
[3328]969Frama-C tool to reason on C code and on the Coq proof-assistant to reason on
[3327]970higher-order functional programs.
972This principle entails that: 1)
[3327]973The inferred synthetic bounds are indeed correct as long as the general purpose
[3336]974tool is; 2) there is no limitation on the class of programs that can be handled
[3327]975as long as the user is willing to carry on an interactive proof.
[3327]977Of course, automation is desirable whenever possible. Within this framework,
978automation means writing programs that give hints to the general purpose tool.
979These hints may take the form, say, of loop invariants/variants, of predicates
980describing the structure of the heap, or of types in a light logic. If these
981hints are correct and sufficiently precise the general purpose tool will produce
982a proof automatically, otherwise, user interaction is required.
[3339]984\paragraph{The Cost plugin and its application to the Lustre compiler.}
[3328]985Frama-C \cite{framac} is a set of analysers for C programs with a
[3327]986specification language called ACSL. New analyses can be dynamically added
[3337]987via a plugin system. For instance, the Jessie plugin allows deductive
[3327]988verification of C programs with respect to their specification in ACSL, with
989various provers as back-end tools.
[3328]990We developed the CerCo Cost plugin for the Frama-C platform as a proof of
[3327]991concept of an automatic environment exploiting the cost annotations produced by
[3417]992the CerCo compiler. It consists of an OCaml program which essentially
[3328]993takes the following actions: 1) it receives as input a C program, 2) it
[3327]994applies the CerCo compiler to produce a related C program with cost annotations,
[3328]9953) it applies some heuristics to produce a tentative bound on the cost of
[3327]996executing the C functions of the program as a function of the value of their
[3328]997parameters, 4) the user can then call the Jessie plugin to discharge the
[3327]998related proof obligations.
999In the following we elaborate on the soundness of the framework and the
1000experiments we performed with the Cost tool on the C programs produced by a
1001Lustre compiler.
[3339]1003\paragraph{Soundness.} The soundness of the whole framework depends on the cost
[3327]1004annotations added by the CerCo compiler, the synthetic costs produced by the
[3337]1005cost plugin, the verification conditions (VCs) generated by Jessie, and the
[3327]1006external provers discharging the VCs. The synthetic costs being in ACSL format,
1007Jessie can be used to verify them. Thus, even if the added synthetic costs are
1008incorrect (relatively to the cost annotations), the process as a whole is still
1009correct: indeed, Jessie will not validate incorrect costs and no conclusion can
1010be made about the WCET of the program in this case. In other terms, the
[3337]1011soundness does not really depend on the action of the cost plugin, which can in
[3327]1012principle produce any synthetic cost. However, in order to be able to actually
1013prove a WCET of a C function, we need to add correct annotations in a way that
1014Jessie and subsequent automatic provers have enough information to deduce their
1015validity. In practice this is not straightforward even for very simple programs
1016composed of branching and assignments (no loops and no recursion) because a fine
1017analysis of the VCs associated with branching may lead to a complexity blow up.
[3339]1018\paragraph{Experience with Lustre.} Lustre is a data-flow language for programming
[3417]1019synchronous systems, with a compiler which targets C. We designed a
[3327]1020wrapper for supporting Lustre files.
1021The C function produced by the compiler implements the step function of the
1022synchronous system and computing the WCET of the function amounts to obtain a
[3328]1023bound on the reaction time of the system. We tested the Cost plugin and the
[3327]1024Lustre wrapper on the C programs generated by the Lustre compiler. For programs
[3424]1025consisting of a few hundred lines of code, the cost plugin computes a
1026WCET and Alt-Ergo is able to discharge all VCs automatically.
[3339]1028\paragraph{Handling C programs with simple loops.}
[3327]1029The cost annotations added by the CerCo compiler take the form of C instructions
[3424]1030that update a fresh global variable called the cost variable by a constant.
1031Synthesizing a WCET of a C function thus consists of statically resolving an
[3327]1032upper bound of the difference between the value of the cost variable before and
[3424]1033after the execution of the function, i.e. finding the instructions
[3327]1034that update the cost variable and establish the number of times they are passed
[3424]1035through during the flow of execution. To perform the analysis the plugin
[3327]1036makes the following assumptions on the programs:
[3337]10371) there are no recursive functions;
10382) every loop must be annotated with a variant. The variants of `for' loops are
[3327]1039automatically inferred.
1041The plugin proceeds as follows.
[3321]1042First the call graph of the program is computed.
[3327]1043Then the computation of the cost of the function is performed by traversing its
[3335]1044control flow graph. If the function $f$ calls the function $g$ 
1045then the function $g$ 
1046is processed before the function $f$. The cost at a node is the maximum of the
[3327]1047costs of the successors.
1048In the case of a loop with a body that has a constant cost for every step of the
1049loop, the cost is the product of the cost of the body and of the variant taken
1050at the start of the loop.
1051In the case of a loop with a body whose cost depends on the values of some free
[3335]1052variables, a fresh logic function $f$ is introduced to represent the cost of the
[3327]1053loop in the logic assertions. This logic function takes the variant as a first
[3335]1054parameter. The other parameters of $f$ are the free variables of the body of the
[3327]1055loop. An axiom is added to account the fact that the cost is accumulated at each
1056step of the loop.
[3337]1057The cost of the function is directly added as post-condition of the function.
[3337]1059The user can influence the annotation by two different means:
10601) by using more precise variants;
10612) by annotating functions with cost specifications. The plugin will use this cost
[3327]1062for the function instead of computing it.
[3339]1063\paragraph{C programs with pointers.}
[3327]1064When it comes to verifying programs involving pointer-based data structures,
1065such as linked lists, trees, or graphs, the use of traditional first-order logic
1066to specify, and of SMT solvers to verify, shows some limitations. Separation
[3431]1067logic is an elegant alternative. It is a program logic
[3327]1068with a new notion of conjunction to express spatial heap separation. Bobot has
[3337]1069recently introduced automatically generated separation
1070predicates to simulate separation logic reasoning in the Jessie plugin where the specification language, the verification condition
[3327]1071generator, and the theorem provers were not designed with separation logic in
[3431]1072mind~\cite{bobot}. CerCo's plugin can exploit the separation predicates to automatically
[3327]1073reason on the cost of execution of simple heap manipulation programs such as an
1074in-place list reversal.
[3417]1076\section{Conclusions and future work}
[3337]1078All the CerCo software and deliverables can be found on the CerCo homepage at~\url{}.
1080The results obtained so far are encouraging and provide evidence that
1081it is possible to perform static time and space analysis at the source level
[3337]1082without losing accuracy, reducing the trusted code base and reconciling the
[3327]1083study of functional and non-functional properties of programs. The
[3316]1084techniques introduced seem to be scalable, cover both imperative and
[3337]1085functional languages and are compatible with every compiler optimisation
[3316]1086considered by us so far.
[3337]1088To prove that compilers can keep track of optimisations
[3316]1089and induce a precise cost model on the source code, we targeted a simple
1090architecture that admits a cost model that is execution history independent.
[3322]1091The most important future work is dealing with hardware architectures
[3316]1092characterized by history dependent stateful components, like caches and
[3428]1093pipelines. The main issue is to assign a parametric, dependent cost
[3432]1094to basic blocks that can be later transferred by the labelling approach to
[3316]1095the source code and represented in a meaningful way to the user. The dependent
[3432]1096labelling approach that we have studied seems a promising tool to achieve
[3428]1097this goal, but more work is required to provide good source level
1098approximations of the relevant processor state.
[3428]1100Other examples of future work are to improve the cost invariant
1101generator algorithms and the coverage of compiler optimizations, to combining
[3432]1102the labelling approach with the type and effect discipline of~\cite{typeffects}
[3428]1103to handle languages with implicit memory management, and to experiment with
1104our tools in the early phases of development. Larger case studies are also necessary
[3337]1105to evaluate the CerCo's prototype on realistic, industrial-scale programs.
[3339]1107% \bibliographystyle{splncs}
1109% \begin{thebibliography}{19}
1111% \bibitem{survey} \textbf{A Survey of Static Program Analysis Techniques}
1112% W.~W\"ogerer. Technical report. Technische Universit\"at Wien 2005
1114% \bibitem{cerco} \textbf{Certified Complexity}. R.M. Amadio, A. Asperti, N. Ayache,
1115% B. Campbell, D. P. Mulligan, R. Pollack, Y. Regis-Gianas, C. Sacerdoti Coen, I.
1116% Stark, in Procedia Computer Science, Volume 7, 2011, Proceedings of the 2 nd
1117% European Future Technologies Conference and Exhibition 2011 (FET 11), 175-177.
[3432]1119% \bibitem{labelling} \textbf{Certifying and Reasoning on Cost Annotations in C
[3339]1120% Programs}, N.  Ayache, R.M. Amadio, Y.R\'{e}gis-Gianas, in Proc. FMICS, Springer
1121% LNCS
1122% 7437: 32-46, 2012.
1123% %, DOI:10.1007/978-3-642-32469-7\_3.
[3432]1125% \bibitem{labelling2} \textbf{Certifying and reasoning on cost annotations of
[3339]1126% functional programs}.
1127% R.M. Amadio, Y. R\'{e}gis-Gianas. Proceedings of the Second international conference
1128% on Foundational and Practical Aspects of Resource Analysis FOPARA 2011 Springer
1129% LNCS 7177:72-89, 2012.
1131% \bibitem{compcert} \textbf{Formal verification of a realistic compiler}. X. Leroy,  In Commun. ACM 52(7), 107–115, 2009.
1133% \bibitem{framac} \textbf{Frama-C user manual}. L. Correnson, P. Cuoq, F. Kirchner, V. Prevosto, A. Puccetti, J. Signoles,
1134% B. Yakobowski. in CEA-LIST, Software Safety Laboratory, Saclay, F-91191,
1135% \url{}.
1137% \bibitem{paolo} \textbf{Indexed Labels for Loop Iteration Dependent Costs}. P.
1138% Tranquilli, in Proceedings of the 11th International Workshop on Quantitative
1139% Aspects of Programming Languages and Systems (QAPL 2013), Rome, 23rd-24th March
1140% 2013, Electronic Proceedings in Theoretical Computer Science, to appear in 2013.
1142% \bibitem{separation} \textbf{Intuitionistic reasoning about shared mutable data
1143% structure} J.C. Reynolds. In Millennial Perspectives in Computer Science,
1144% pages 303–321, Houndsmill, Hampshire, 2000. Palgrave.
1146% \bibitem{lustre} \textbf{LUSTRE: a declarative language for real-time
1147% programming}
1148% P. Caspi, D. Pilaud, N. Halbwachs, J.A. Plaice. In Proceedings of
1149% the 14th ACM SIGACT-SIGPLAN symposium on Principles of programming languages ACM
1150% 1987.
1152% \bibitem{correctness} \textbf{On the correctness of an optimising assembler for
1153% the intel MCS-51 microprocessor}.
1154%   D. P. Mulligan, C. Sacerdoti Coen. In Proceedings of the Second
1155% international conference on Certified Programs and Proofs, Springer-Verlag 2012.
1157% \bibitem{proartis} \textbf{PROARTIS: Probabilistically Analysable Real-Time
1158% Systems}, F.J. Cazorla, E. Qui\~{n}ones, T. Vardanega, L. Cucu, B. Triquet, G.
1159% Bernat, E. Berger, J. Abella, F. Wartel, M. Houston, et al., in ACM Transactions
1160% on Embedded Computing Systems, 2012.
1162% \bibitem{embounded} \textbf{The EmBounded project (project paper)}. K. Hammond,
1163% R. Dyckhoff, C. Ferdinand, R. Heckmann, M. Hofmann, H. Loidl, G. Michaelson, J.
1164% Serot, A. Wallace, in Trends in Functional Programming, Volume 6, Intellect
1165% Press, 2006.
1167% \bibitem{matita}
1168% \textbf{The Matita Interactive Theorem Prover}.
1169% A. Asperti, C. Sacerdoti Coen, W. Ricciotti, E. Tassi.
1170% 23rd International Conference on Automated Deduction, CADE 2011.
1172% \bibitem{typeffects} \textbf{The Type and Effect Discipline}. J.-P. Talpin,
1173%  P. Jouvelot.
1174%   In Proceedings of the Seventh Annual Symposium on Logic in Computer Science
1175% (LICS '92), Santa Cruz, California, USA, June 22-25, 1992.
1176% IEEE Computer Society 1992.
1178% \bibitem{stateart} \textbf{The worst-case execution-time problem overview of
1179% methods
1180% and survey of tools.} R. Wilhelm et al., in  ACM Transactions on Embedded
1181% Computing Systems, 7:1–53, May 2008.
1183% %\bibitem{proartis2} \textbf{A Cache Design for Probabilistic Real-Time
1184% % Systems}, L. Kosmidis, J. Abella, E. Quinones, and F. Cazorla, in Design,
1185% % Automation, and Test in Europe (DATE), Grenoble, France, 03/2013.
1187% \end{thebibliography}
Note: See TracBrowser for help on using the repository browser.