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,442eb9212004f30 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 14 Jul 2008 15:12:46 +0200 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Problem using Ada.Text_IO.Modular_IO References: <1215965011.20645.42.camel@K72> <5uyek.117084$102.99047@bgtnsc05-news.ops.worldnet.att.net> In-Reply-To: <5uyek.117084$102.99047@bgtnsc05-news.ops.worldnet.att.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <487b50de$0$7537$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 14 Jul 2008 15:13:02 CEST NNTP-Posting-Host: d3a90c8c.newsspool1.arcor-online.net X-Trace: DXC=U[CQeTWWfoYYQ5E:lZLh>_cHTX3j]2I3XMT]bVFY X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:1149 Date: 2008-07-14T15:13:02+02:00 List-Id: anon schrieb: > When the CPU or FFU executes a single arithmetic instruction it uses the > build-in CPU Carry flag to detect a Overflow/Underflow condition for those > types that are define in the Standard/System packages. It turns out that the CPU instructions for "mod 2**64" types are the very same as the CPU instructions for Unsigned_64. Assuming you get an advantage from using hardware overflow flags, they will thus be had for either type. > Which is faster > than a set of routines that the compiler generates for a new user type. Q: What routines does the compiler generate for Unsigned_64 but not for "mod 2**64" and vice versa? A: None. Q: What routines does the compiler generate for mod 2**5? A: None that have a jump to constraint error handlers. (Not surprisingly; and see below.) Some that do fast, efficient, modular operations in hardware. (Not surprisingly; see below.) None that could replaced with predefined ones because there is no predefined type with the same properties as "mod 2**5". Not on earth, at least, as far as I can tell. > Actually, in the case of 2**5 the arithmetic > function is done on the processor 8-bit word and then the result is > compared to see if the result is with the range of 2**5. A lot of > instructions are generated instead of only three for build-in types: What makes you think that 2**5 artithmetic is necessarily expensive? It is modular arithmetic on a power of 2. Ada compilers will in many cases do better than what you have outlined. Code for a "mod 2**5" type: type M5 is mod 2**5; function Double_It(Item: M5) return M5 is begin return item + item; end Double_It; $ gnatmake -gnatwa -gnato -O -fno-inline mod5.adb 0000000000000000 : 0: 01 ff add %edi,%edi 2: 89 f8 mov %edi,%eax 4: 83 e0 1f and $0x1f,%eax 7: c3 retq %eax is a 32-bit word, and no 8-bit AL or AH register is mentioned. ADD is safe because %edi is bound to contain values of type "mod 2**5", so small that addition can never set a 32bit CPU's unsigned overflow flag. The rest ist just clearing the sequence of carried bits because this is how "mod 2**5" works in binary hardware. Again -gnato is used for turning checks on, in case you had overlooked this when answering. To repeat, I have _never_ seen different code produced for the same algorithm using either Unsigned_N or mod 2**N. Could you give one actual, compilable example so we could convince ourselves that what you claim can be found to be true, concerning the superiority of Unsigned_N over mod 2+*N? -- Georg Bauhaus Y A Time Drain http://www.9toX.de