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-Thread: a07f3367d7,cae92f92d6a1d4b1 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe21.iad.POSTED!00000000!not-for-mail From: Brad Moore User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada.Execution_Time References: <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1wmsukf0wglz3$.odnzonrpayly.dlg@40tude.net><6n1c5myuf2uz$.10jl3ln7il3aq.dlg@40tude.net><8n0mgnFv2sU1@mid.individual.net><1n3o55xjdjr9t.1u33kb75y2jfl$.dlg@40tude.net><8n1142Fto2U1@mid.individual.net><1o5cbm4b1l20d$.19winbma6k5qw.dlg@40tude.net><8n4mskF7mmU1@mid.individual.net><8nm30fF7r9U1@mid.individual.net> <8o0p0lF94rU1@mid.individual.net> <8o4k3tFko2U1@mid.individual.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 68.145.218.234 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe21.iad 1294242933 68.145.218.234 (Wed, 05 Jan 2011 15:55:33 UTC) NNTP-Posting-Date: Wed, 05 Jan 2011 15:55:33 UTC Date: Wed, 05 Jan 2011 08:55:34 -0700 Xref: g2news2.google.com comp.lang.ada:17299 Date: 2011-01-05T08:55:34-07:00 List-Id: On 03/01/2011 2:33 PM, Randy Brukardt wrote: > if you can afford megabucks to have a compiler runtime tailored to > your target hardware (and compiler vendors love such customers), then you > probably could find a use for in a hard real-time system. > > But the typical off-the-shelf implementation is not going to be useful for > anything beyond gross guidance. That's probably enough for soft real-time > systems anyway; and the facilities are useful for profiling and the like > even without any strong connection to reality. > > But it doesn't make sense to assume tight matches unless you have a very > controlled environment. And if you have that environment, a language-defined > package doesn't buy you anything over roll-your-own. So I would agree that > the existence Ada.Execution_Time really doesn't buy anything for a hard > real-time system. > > I suppose there are others that disagree (starting with Alan Burns). I think > they're wrong. > Keep in mind that the IRTAW proposals tend to get put into the language > without much resistance from the majority of the ARG. Most of us don't have > a enough real-time experience to really be able to have a strong opinion on > a topic. So we don't generally oppose the basic reason for a proposal. > > We simply spend time on polishing the proposals into acceptable RM language > (which is usually a large job by itself; the proposals tend to be very > sloppy). Rarely do we object to the proposal itself, in large part because > we simply don't have enough energy to think in great detail about every > proposal. > > It's best to think of the Annex D stuff as designed and proposed separately > by a small subgroup. (There's a similar dynamic for some other areas as > well, numerics coming to mind.) That small subgroup may have a different > world-view than the rest of us. To get a perspective on some of the IRTAW thinking with respect to execution time, one might want to have a look at the paper; "Execution-Time Control For Interrupt Handling", a proposal from the most recent IRTAW. http://www.sigada.org/ada_letters/apr2010/paper3.pdf The paper expresses an interest in accounting for the time spent during the handling of interrupts, and tracking this separately rather than charge the execution time to the current running task, as is currently the case for most current implementations of Ada.Execution_Time. The intent is to improve the accuracy of execution time measurement and computing WCET so that task budgets can be tighter allowing for higher CPU utilization. --BradM