Changeset 3428
- Timestamp:
- Feb 12, 2014, 11:30:21 AM (7 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
Papers/fopara2013/fopara13.tex
r3427 r3428 814 814 unpredictable amount of time in I/O. What is interesting is the reaction time 815 815 that measure the time spent between I/O events. Moreover, we are interested in 816 predicting and ruling out programs that crash running out of space on acertain817 input .816 predicting and ruling out crashes due to running out of space on certain 817 inputs. 818 818 Therefore we need to look for a statement that talks about sub-runs of a 819 819 program. The most natural statement is that the time predicted on the source … … 879 879 dependencies on the `non-functional' parts of the state. 880 880 881 The non-functional state has no correspondence in the high level state and does 882 not influence the functional properties. What can be done is to expose the 883 non-functional state in the source code. We present here the basic 884 intuition in a simplified form: the technical details that allow us to handle the 885 general case are more complex and can be found in~\cite{paolo}. We add 886 to the source code an additional global variable that represents the 887 non-functional state and another one that remembers the last labels emitted. The 888 state variable must be updated at every label emission statement, using an 889 update function which is computed during static analysis too. The update 890 function associates to each label a function from the recently emitted labels 891 and old state to the new state. It is computed by composing the semantics of every 892 instruction in a basic block and restricting it to the non-functional part of 893 the state. 881 The non-functional state is not directly related to the high level 882 state and does not influence the functional properties. What can be 883 done is to expose key aspects of the non-functional state in the 884 source code. We present here the basic intuition in a simplified form: 885 the technical details that allow us to handle the general case are 886 more complex and can be found in~\cite{paolo}. We add to the source 887 code an additional global variable that represents the non-functional 888 state and another one that remembers the last few labels emitted. The 889 state variable must be updated at every label emission statement, 890 using an update function which is computed during static analysis 891 too. The update function associates to each label a function from the 892 recently emitted labels and old state to the new state. It is computed 893 by composing the semantics of every instruction in a basic block and 894 restricting it to the non-functional part of the state. 894 895 895 896 Not all the details of the non-functional state needs to be exposed, and the … … 902 903 program. Moreover, at any moment the user, or the invariant generator tools that 903 904 analyse the instrumented source code produced by the compiler, can decide to 904 trade precision of the analysis for simplicity by approximating the parametric905 cost with safe non parametric bounds. Interestingly, the functional analysis of905 trade precision of the analysis for simplicity by approximating the 906 cost with safe bounds that do not depend on the processor state. Interestingly, the functional analysis of 906 907 the code could determine which blocks are executed more frequently in order to 907 908 use more aggressive approximations for the ones that are executed least. … … 1063 1064 The most important future work is dealing with hardware architectures 1064 1065 characterized by history dependent stateful components, like caches and 1065 pipelines. The main issue consists in assigninga parametric, dependent cost1066 pipelines. The main issue is to assign a parametric, dependent cost 1066 1067 to basic blocks that can be later transferred by the labeling approach to 1067 1068 the source code and represented in a meaningful way to the user. The dependent 1068 1069 labeling approach that we have studied seems a promising tool to achieve 1069 this goal, but the cost model generated for a realistic processor could be too 1070 large and complex to be exposed in the source code. Further study is required 1071 to evaluate the technique on a realistic processor and to introduce early 1072 approximations of the cost model to make the technique feasible. 1073 1074 Examples of further future work consist in improving the cost invariant 1075 generator algorithms and the coverage of compiler optimizations, in combining 1070 this goal, but more work is required to provide good source level 1071 approximations of the relevant processor state. 1072 1073 Other examples of future work are to improve the cost invariant 1074 generator algorithms and the coverage of compiler optimizations, to combining 1076 1075 the labeling approach with the type and effect discipline of~\cite{typeffects} 1077 to handle languages with implicit memory management, and in experimentingwith1078 our tools in early development phases. Some larger case study isalso necessary1076 to handle languages with implicit memory management, and to experiment with 1077 our tools in the early phases of development. Larger case studies are also necessary 1079 1078 to evaluate the CerCo's prototype on realistic, industrial-scale programs. 1080 1079
Note: See TracChangeset
for help on using the changeset viewer.