Specifying time limits in source code ?

Hello all,


I am doing research (for my PhD) in the area of implementing real-time
systems.


Design methodology in this world is very much focussed on timely
response of the system. For example, you can specifiy time limits
within which the system should respond on an event.


However, as soon as you step from design to implementation, support is
very limited. As designer, the only thing you can do is implement the
system, and then measure whether the code you wrote is fast enough.
If not, it is back to the design, if it is, what does it prove ?


Therefore, it would be better if a hard guarantee could be given that
the processor will never take more than x (micro) seconds for a
certain piece of code. A compiler can help here. It knows which code
it produces, I can put information about # clock-cycles of each opcode
into it, et voila, it can calculate exactly what I want to know.


For the designer, it would be enough to be able to specify an upper
time limit for some code, and the compiler should accept the program
if it is able to produce code which meets the dead line.


At the processor-side, things are a bit more difficult, but not impossible.
- I would have to specify the max #iterations of each loop construct.
- There is no way that the compiler can take scheduling of tasks
    (including interrupts) into account. In other words, the designer must
    specify time limits such that scheduling poses no threat of violating
    the dead line. In the context of hard real-time systems, this is a
    problem with a known solution.
- The compiler may move code outside the fragment, which affects timing.
    The easiest solution is to forbid this. With some thought, a better
    solution is possible imho.
- Also, current processors do prefetching and out of order execution
    which is very unpredictable (this may be considered as a form of
    run-time optimization).
    - Current `normal' processors in real-time systems are not always that
        advanced, so the problem may not even exist in some cases.
    - If it does exist, at least it will only make the program run faster
        not slower, which means that the time limit will always be met.
        However, it may cause a grossly over-estimated time limit.
        In some projects the time saved by not having somebody check the
        timing of the code may outweigh the extra cost of the processor.
    - Maybe execution time of an opcode is not a good measure, in which
        case there may be alternative methods, such as counting memory refs.


Assuming that some else would have considered the above, I was
surprised to learn that the archive of comp.compilers had no
discussion about specifying time-limits on fragments of programs.




I'd like to include some of the stuff in my thesis, so I need some
references to work done in this direction.


There fore
    Do these beasts exist ?
    Is there work being done on this kind of compilers ?
    Is it just a silly idea of mine ?


Thank you for any information or pointers on this subject.




Albert

Return to the comp.compilers page.
Search the comp.compilers archives again.