Re: Worst Case Execution Time Tool?

[Ted Dennison<dennison@telepath.com>]

In article <3C0F7B36.52960668@computer.org>, StationSteve says...
>
>Of course.  Er, I mean sorry, I guess I should have said that I was looking 
>for a *practical* tool that could *productively* address a *real world* 
>problem! ;-)
>
>Ted Dennison wrote:
>> Ah. So we aren't looking for something that can handle any old program 
>> (which it still seems to be would be reducable to the Halting Problem), but 
>> rather one that can handle programs that fit certian restrictions.

:-)

For that to be accurate though, you'd have to be able to say that all programs
that don't fit within the restrictions are not "real world" programs for some
reason. That could be the case I suppose. However, I'd bet quite a few "real
world" programs wouldn't meet all the restrictions in any such existing tool.
Certianly "No recursion" and "no loops with a dynamicly determined amount of
iterations" (which is what Stuart said) would take out a great deal of the "real
world" code I have seen. 

For instance, just about anything that handles terminated I/O would be out. A
lot of dynamic data structure code would be out too. I could easily see where a
hard realtime app might want to measure the worst-case execution time of a list
traversal (eg: the scheduler's list of scheduled tasks). It'd be a pretty darn
smart tool if it could handle that, no matter how the list is implemented.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.