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: 103376,cae92f92d6a1d4b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Ada.Execution_Time Date: Sat, 01 Jan 2011 16:01:45 +0000 Organization: A noiseless patient Spider Message-ID: 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> <8o8ptdF35oU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="dFCm8HWntFqmDIilBLqEJQ"; logging-data="8806"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZpS6kfBJI98PQpJ+4enIHr2eHNlvVDpk=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin) Cancel-Lock: sha1:5h2nJkRg64hlx4Vj62MbDQO4VGA= sha1:3oPafrlgiK46WOhfn7ZOrNSDBJo= Xref: g2news2.google.com comp.lang.ada:17266 Date: 2011-01-01T16:01:45+00:00 List-Id: Simon Wright writes: > Niklas Holsti writes: > >> The question is then if the compiler/system vendors will take the >> trouble and cost to customise Ada.Execution_Time for a particular >> board/computer, or if they will just use the general, >> lowest-denominator but portable service provided by the kernel. Dmitry >> indicates that GNAT on VxWorks takes the latter, easy way out. > > The latest supported GNAT on VxWorks (5.5) actually doesn't implement > Ada.Execution_Time at all (well, the source of the package spec is > there, adorned with "pragma Unimplemented_Unit", just like the FSF > 4.5.0 sources and the GNAT GPL sources -- unless you're running on > Cygwin or MaRTE). Actually, Dmitry's complaint was that time (either from Ada.Calendar.Clock, or Ada.Real_Time.Clock, I forget) wasn't as precise as it can easily be on modern hardware, being incremented at each timer interrupt; so if your timer ticks every millisecond, that's your granularity. This could easily be changed (at any rate for Real_Time), but doesn't I believe necessarily affect what's to be expected from delay/delay until, or Execution_Time come to that.