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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,edfa88b682578b7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-26 08:52:18 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!82-43-33-75.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Overhead for type conversions? Date: Sat, 26 Jul 2003 16:54:13 +0100 Message-ID: References: NNTP-Posting-Host: 82-43-33-75.cable.ubr01.croy.blueyonder.co.uk (82.43.33.75) X-Trace: news.uni-berlin.de 1059234736 19259829 82.43.33.75 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:40841 Date: 2003-07-26T16:54:13+01:00 List-Id: "Bobby D. Bryant" wrote in message news:pan.2003.07.25.01.01.43.5699@mail.utexas.edu... > Given these declarations - > > type f1 is new float; > type f2 is new float; > > function "*"( left : in f1; right : in f2 ) return f1 is > begin > return( left * f1( right ) ); > end "*"; > > and given that run-time range checks are enabled, should I expect my > compiler to execute range checking code for each f1*f2 multiplication, > or will the compiler conclude from the definitions that the two types > are always convertible without error regardless of the specific value, > and thus not generate any code for a range check? The type Standard.Float is unconstrained (RM95 3.5.7(12)), so the types f1 and f2 derived from it will also be unconstrained (RM95 3.4(6)). Thus, there will be no range checks (there may be other checks). I would also suggest that a function like this should be declared inline, since it is likely that the eliminated call and return code would be bigger (as well as much slower) than the intrinsic code for the multiplication anyway. Furthermore, should f1 and/or f2 become constrained in the future, such inlining could give an optimising compiler the opportunity to eliminate range checks (and to perform other optimisations). > (In practice the compiler is GNAT.) I can't help you with the specifics of GNAT; sorry. -- Nick Roberts Jabber: debater@charente.de [ICQ: 159718630]