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=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.bbs-scene.org!eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: hreba Newsgroups: comp.lang.ada Subject: Re: integers of 1, 2, 4 bytes Date: Sun, 15 Jun 2014 18:31:27 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net 2IpezxO6V7V4T6H3RIzaqAeSEVCpx4pvOXSj5umSxXAF9Nw3I9 Cancel-Lock: sha1:zvvX1Xg+jxaaZKY4wdASaB875u0= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: X-Original-Bytes: 4238 Xref: number.nntp.dca.giganews.com comp.lang.ada:186940 Date: 2014-06-15T18:31:27-03:00 List-Id: On 06/15/2014 04:26 PM, Stefan.Lucks@uni-weimar.de wrote: > On Sun, 15 Jun 2014, hreba wrote: > >> My Ada book says that range checks are applied to constrained subtypes >> (like that one) but not to unconstrained subtypes, but but overflow >> checks are applied nevertheless. So I came up with >> >> type Int16 is range -32768 .. 32767; >> for Int16'Size use 16; >> type INT is new Int16'Base; > > If you *want* to get rid of range checks, there are pragmas to disable > them. (Not that I would consider this a good idea at all ...). And I am > not a language lawyer, but I claim that the Ada compiler will perform > exactly the same range checks for INT, as it does for Int16 (see below). > > So please just use Int16 as defined in > > type Int16 is range -32768 .. 32767; > for Int16'Size use 16; > > and disable range checking when and where you really need aggressively > optimized codes (e.g., in the innermost loop ...). > > So why does Ada perform range checks for INT? The reason is that INT is > not "unconstrained", but actually in the range INT'First .. INT'Last for > some INT'First and INT'Last of the compilers choice. INT'First might be > smaller than Int16'First, and INT'Last might exceed Int16'Last, but > there are still ranges to be checked. And, given the Size attribute, > there appears no choice for the compiler anyway: INT'FIRST=Int16'First > and INT'Last=Int16'Last imply exactly the same range chekcs for INT as > for Int16. > >> as a more efficient definition. > > If you have specific performance constraints, you should try to optimize > specific subprograms or code fragments, e.g., by disabling range checks > within the innermost loop or so. > >> Now it seems the range specification doesn't matter any more and that >> I could equally write >> >> type Int16 is range -1 .. 1; >> for Int16'Size use 16; >> type INT is new Int16'Base; >> >> Would you really define a 16 bit integer type this way? > > Firstly, this makes your program hard to read, so this is poor software > engineering. Secondly, it does not do what you want it to do -- i.e., it > does not omit the range checks. And finally, the Ada compiler has a > great deal of freedom what Int16'Base actually is. While I find it hard > to imagine that an Ada compiler for any target machine with 2-complement > arithmetic would not set Int16'Base to the range -2**15 .. +2**15-1, the > Ada compiler might still surprise you. > >> And how about non-negative types? Would the following have the values >> 0 .. 255? > > Now for non-negative integers, there are modular types, which actually > support arithmetic operations without range checking: > > type Byte is mod 2**8; > for Byte'Size use 8; > > (And similar for 2- and 4-byte arithmetic ...) > > > ------ I love the taste of Cryptanalysis in the morning! ------ > > --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany-- In my response to Niklas' answer I explained in some more detail what I wanted. Now it is clear to me that my type definition does not do that. Thanks for your comments about style and compiler freedom. -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil