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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Community Input for the Maintenance and Revision of the Ada Programming Language Date: Wed, 6 Sep 2017 16:21:32 -0500 Organization: JSA Research & Innovation Message-ID: References: <4dc188de-802b-41ad-9cdd-b8246eb9a1c7@googlegroups.com> <47cc6474-8b75-4644-92d0-bd1f694c20e7@googlegroups.com> <338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com> Injection-Date: Wed, 6 Sep 2017 21:21:32 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="5889"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47955 Date: 2017-09-06T16:21:32-05:00 List-Id: "Johan Söderlind Åström" wrote in message news:e9e2556d-9b23-4e7f-9058-776dd506f73c@googlegroups.com... >On Sunday, September 3, 2017 at 3:30:23 AM UTC+2, Randy Brukardt wrote: >> "Johan Söderlind Åström" wrote in message >> news:338b355a-dee4-4c73-b00e-09d9a8430fb1@googlegroups.com... >> ... >> >procedure Algorithm (Item : Integer_Array) is >> > use Ada.Assertions; >> > X : Integer_Array (0 .. Item'Length - 1) with Address => Item'Address; >> >> The use of address clauses other than for interfacing is evil (and not >> guaranteed to work in the case of overlaying Ada code). Don't do that. >> >> You can change the bounds of an array with a type conversion to a >> constrained subtype, which is likely to be cheaper and not break if you >> change compilers. >What do you mean with cheaper? Faster execution?, Less memory footprint? Both. The address clause adds an extra level of indirection that the type conversion doesn't necessarily add. (In Janus/Ada, the conversion would remove or replace the bounds descriptor, making the access cost identically to the original array accesses; an address clause always adds a level of indirection.) But I forgot about the cost to copy the array (usually insignificant, but not always). >Which compiler will break my code? Any compiler could; 13.3(16) says that it only required for 'Address to have a "useful result" if the prefix is aliased or by-reference (neither which is true for the parameter Item of type Integer_Array). Ergo, such a usage is not portable (even if many compilers allow it). Dunno if it will actually break in any implementation, but it is best to avoid these sorts of non-portable things. As discussed, procedure Algorithm (Item : Integer_Array) is subtype Zero_Array is Integer_Array (0 .. Item'Length - 1); X : constant Zero_Array := Zero_Array (Item); has the same effect (modulo probably making an extra copy of the data), is always going to work (assuming Item'Length is short enough to fit in the index subtype - the point of Stephen Leake), doesn't need any assertions, and is much easier to read. >I do not know how Ada accesses a array element internally. But a zero >indexed array must be cheaper than a custom indexed array, see: > >Accessing nth element from zero indexed array: >(base_address + index*element_size). > >Accessing nth element from a custom indexed array: >(base_address + (index - first)*element_size) In most cases, that is not an issue. Whenever Item'First is static (that is known to the compiler), the compiler will fold it into the base address so the cost is the same. (And there is a cost to rebasing the array, no matter how you do it.) Specifically, the general form: (base_address + (index - first)*element_size) is the same as: (base_address - (first*element_size) + (index*element_size)) In the usual case, when both first and element_size are known to the compiler, the code generation will be ((base_address - (first*element_size)) + (index*element_size)) with the first part calculated by the compiler and generated as a single item. The only runtime operations are the + and second *, just as in the zero-based form. Moral: Compilers can eliminate most of the supposedly extra costs; it pays only to worry about those that are known (via experiment) to be significant in the runtime of a program. (The 90-10 rule says that the performance of 90% of the code has no effect on the result.) Moral2: Premature optimization is the root of much evil. Only worry about the performance of code that is demonstrably too slow. Otherwise, readability and maintainability are the most important goals after correctness. YMMV. Randy. I do not think that accessing a element from a array is a complicated thing and starting from a zero indexed array is even simpler, then why would a compiler not guarantee such a simple thing to work?