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: 
 g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada.Execution_Time
Date: Mon, 20 Dec 2010 18:37:24 -0600
Organization: Jacob Sparre Andersen
Message-ID: <ieoss6$efg$1@munin.nbi.dk>
References: <ie1ih9$d02$1@news.eternal-september.org>
 <ie2v2k$aps$1@tornado.tornevall.net> <ie3gjn$oj$1@news.eternal-september.org>
 <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net>
 <ie91co$cko$1@news.eternal-september.org> <ief8ou$27ij$1@news.ett.com.ua>
 <iejsu9$lct$1@news.eternal-september.org>
 <op.vnxz4kmplzeukk@jellix.jlfencey.com> <8n66ucFnavU1@mid.individual.net>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1292891847 14832 69.95.181.76 (21 Dec 2010 00:37:27 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 21 Dec 2010 00:37:27 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Xref: g2news1.google.com comp.lang.ada:16087
Date: 2010-12-20T18:37:24-06:00
List-Id: <comp.lang.ada>

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:8n66ucFnavU1@mid.individual.net...
...
> A problem that you don't mention is that the use of Duration may cause 
> loss of precision. Duration'Small may be as large as 20 milliseconds (RM 
> 9.6(27)), although at most 100 microseconds are advised (RM 9.6(30)), 
> while the Time_Span resolution must be 20 microseconds or better (RM 
> D.8(30)). Perhaps Annex D should require better Duration resolution?

The rules for Duration were chosen so that it would not require more than a 
32-bit type. Not all embedded processors are set up to handle 64-bit numbers 
efficiently...

(As time moves on, this is less of a consideration than it used to be, but 
it still seems like a possible problem. Time_Span itself doesn't suffer from 
the problem since as a private type it can be represented as a record with 
several components. Duration is a visible fixed point type.)