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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,31d67020d4b04d5b X-Google-Attributes: gid103376,public From: Niklas Holsti Subject: Re: Simple Real_Time.Time_Span question Date: 1998/10/17 Message-ID: <3627BFC5.8C179E2F@icon.fi>#1/1 X-Deja-AN: 401948052 Content-Transfer-Encoding: 7bit References: <6vvsgo$rvo$1@nnrp1.dejanews.com> <7003e4$534@hacgate2.hac.com> <700ic6$q1p$1@nnrp1.dejanews.com> <702oll$1v4$1@news.hal-pc.org> <705n7o$ro2$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: Space Systems Finland Ltd Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-10-17T00:00:00+00:00 List-Id: dennison@telepath.com wrote: [ snip ] > I don't think there is much doubt that the specification of Ada.Real_Time is > seriously broken in this respect. Until this can be addressed properly, I > would implore Ada vendors who support this annex to provide a child package > with subprograms capable of converting between Float and Time_Span. I realize > Float as a type has its problems too, but between Float and Duration I think > we would have the needs of Real-time programs fairly well covered. In an earlier posting, I suggested converting Time_Span to Float by means of division by Time_Span_Unit, yielding an Integer, then multiplying by Time_Unit, giving floating-point seconds. While this works, in experimenting with GNAT (3.05) I noticed that there is a dynamic range problem: Time_Unit is 1 nanosecond and Integer is 32 bits, which means that the above conversion method will only work for a Time_Span less than about 2.14 seconds ( = 2**31 nanoseconds) before the division overflows. In a theoretical implementation with 16-bit Integer and a Time_Unit of 20 microseconds, the limit would be about 0.66 seconds. So although the conversion to floating point is defined by Ada.Real_Time, the range may be too narrow for the direct algorithm. A work-around is possible: first divide the given Time_Span by Integer'last * Time_Span_Unit. Multiply the quotient by Integer'last * Time_Unit; convert the remainder as suggested above; then add the results. This extends the convertible Time_Span range by a factor of Integer'last, to around 146 years for GNAT. While this work-around solves the range problem, it is a little cumbersome. My suggestion for an LRM change is to replace "Integer" in the Ada.Real_Time operations by a local integer type (named Time_Count, say) of implementation-defined range, sufficient for some standard Time_Span range such as 1 day or, preferably, 50 years. GNAT could choose a 64-bit integer for this type, giving a range of 292 years by my calculations. This should be enough for anybody :-) - Niklas Holsti