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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: 64-bit unsigned integer? Date: Sun, 25 Feb 2018 15:20:15 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <63f986fd-662a-47e7-adf9-5fddc243ac45@googlegroups.com> <68a00dac-e58c-48b7-b2cd-edf44b86d73c@googlegroups.com> NNTP-Posting-Host: b3/KWLDSh2Q785SrqKUcjA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:50637 Date: 2018-02-25T15:20:15+01:00 List-Id: On 2018-02-25 14:59, MM wrote: > On Sunday, 25 February 2018 13:23:24 UTC, Dmitry Kazakov wrote: >> On 2018-02-25 13:54, MM wrote: >>> I don't want to go the BigNum route - too heavyweight. Implementing it >>> efficiently myself may require access to the processor's condition code >>> registers, so this feels like an assembly language approach? >> >> Why, it is straightforward because you have no negatives. Something like >> this: >> >> package Unsigneds_64 is > > That is a pretty cool solution, and thanks for coding it so quickly! Caution, I didn't test it! > I was rather hoping for a one-liner type definition, but I suppose I can't have > everything! Well, what you wrote is legal Ada. It would be nice if RM required such things to be always legal even if the hardware would not play with. P.S. There is a tricky part of intermediate results. RM requires the outcome be mathematically correct, it does not require Constraint_Error necessarily raised if some intermediate result overflows. The implementation like I suggested would always raise Constraint_Error. RM approach looks nice mathematically, and also allows optimizations and reordering, but that becomes less attractive from the design by contract POV as the same code may behave differently on different machines/vendors. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de