From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ba6120170d8e7faf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-06 13:53:47 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!xyzzy!nntp From: StationSteve Subject: Re: Worst Case Execution Time Tool? X-Nntp-Posting-Host: hl20s04182.tx.boeing.com Content-Type: text/plain; charset=us-ascii Message-ID: <3C0FE2DE.4BD905B9@computer.org> Sender: nntp@news.boeing.com (Boeing NNTP News Access) Content-Transfer-Encoding: 7bit Organization: The Boeing Company X-Accept-Language: en References: <3C0D536C.2E059EE8@computer.org> <0CdP7.48989$xS6.81382@www.newsranger.com> <3C0E5927.5657963A@baesystems.com> <3C0F7B36.52960668@computer.org> Mime-Version: 1.0 Date: Thu, 6 Dec 2001 21:27:58 GMT X-Mailer: Mozilla 4.61 [en] (Win95; U) Xref: archiver1.google.com comp.lang.ada:17535 Date: 2001-12-06T21:27:58+00:00 List-Id: Ok, do you have time to educate me a little bit? Why would a tool have to be "pretty darn smart" to measure the worst-case execution time of a list traversal? What's the big driver in making such a thing hard to do? How hard are we talking? Ph.D/New Theory Required hard or Grad Student Thesis hard or Kappa-Key undergrad hard or Lock-the-new-hire-in-the-lab-just-get-it-done hard? Ted Dennison wrote: > 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.