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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cae92f92d6a1d4b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!news.nobody.at!texta.sil.at!newsfeed01.chello.at!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada.Execution_Time Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Sun, 26 Dec 2010 11:25:13 +0100 Message-ID: <1akm5muxu9zni.mu91b7pubqw0$.dlg@40tude.net> NNTP-Posting-Date: 26 Dec 2010 11:25:11 CET NNTP-Posting-Host: 0016a0b3.newsspool2.arcor-online.net X-Trace: DXC=ggm=3T[E4_f;iVb[J9ZZP`A9EHlD;3Ycb4Fo<]lROoRa8kFHYeAd?e9nX=S;c X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:17113 Date: 2010-12-26T11:25:11+01:00 List-Id: On Sat, 25 Dec 2010 13:31:27 +0200, Niklas Holsti wrote: > Dmitry A. Kazakov wrote: >> On Sat, 18 Dec 2010 23:20:20 +0200, Niklas Holsti wrote: > ... >>> The concept and measurement of "the execution time of a task" does >>> become problematic in complex processors that have hardware >>> multi-threading and can run several tasks in more or less parallel >>> fashion, without completely isolating the tasks from each other. >> >> No, the concept is just fine, > > Fine for what? For schedulability analysis, fine for on-line scheduling, > ... ? Applicability of a concept is not what makes it wrong or right. > However, this is a side issue, since we are (or at least I am) > discussing what the RM intends with Ada.Execution_Time, which must be > read in the context of D.2.1, which assumes that there is a clearly > defined set of "processors" and each processor executes exactly one > task at a time. Why? Scheduling does not need Ada.Execution_Time, it is the Ada.Execution_Time implementation, which needs some input from the scheduler. How do you explain that CPU_Time, a thing about time sharing, appears in the real-time systems annex D? > You have > not given any arguments, based on the RM text, to support your position. I am not a language lawyer to interpret the RM texts. My argument was to common sense. >>>> I am not a language lawyer, but I bet that an implementation of >>>> Ada.Execution_Time.Split that ignores any CPU frequency changes >>>> when summing up processor ticks consumed by the task would be >>>> legal. >>> Whether or not such an implementation is formally legal, that would >>> require very perverse interpretations of the text in RM D.14. >> >> RM D.14 defines CPU_Tick constant, of which physical equivalent (if >> we tried to enforce your interpretation) is not constant for many >> CPU/OS combinations. > > The behaviour of some CPU/OS is irrelevant to the intent of the RM. Nope, one of the killer arguments ARG people deploy to reject most reasonable AI's is: too difficult to implement on some obscure platform for which Ada never existed and never will. (:-)) > As > already said, an Ada implementation on such CPU/OS could use its own > mechanisms for execution-time measurements. Could or must? Does GNAT this? >> On a such platform the implementation would be as perverse as RM D.14 >> is. But the perversion is only because of the interpretation. > > Bah. I think that when RM D.14 says "time", it really means time. You > think it means something else, perhaps a CPU cycle count. I think the > burden of proof is on you. > > It seems evident to me that the text in D.14 must be interpreted using > the concepts in D.2.1, "The Task Dispatching Model", which clearly > specifies real-time points when a processor starts to execute a task and > stops executing a task. To me, and I believe to most readers of the RM, > the execution time of a task is the sum of these time slices, thus a > physical, real time. If that was the intent, then I really do not understand why CPU_Time was introduced in addition to Ada.Real_Time.Time / Time_Span. > And you still have not defined what you mean by "simulation time", and > how you come there from the RM text. Simulation time is a model of real time a physical process might have under certain conditions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de