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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fae85d3a03b5f78c X-Google-Attributes: gid103376,public From: Tom Moran Subject: Re: Fixed-point Date: 1997/03/28 Message-ID: <333C27FB.73B7@bix.com>#1/1 X-Deja-AN: 229124099 References: <333C08A7.446B9B3D@innocon.com> Organization: InterNex Information Services 1-800-595-3333 Reply-To: tmoran@bix.com Newsgroups: comp.lang.ada Date: 1997-03-28T00:00:00+00:00 List-Id: > Jack Crenshaw's "Programmer's Toolbox" column in *Embedded Systems > Programming* has been discussing > ... > fixed-point operations are so slow in Ada He apparently once tried Ada in the early '80s and has been repeating obsolete nonsense ever since. Clearly if you define a 35 bit fixed point field, and your compiler lets you, arithmetic will be a bit slow, just like asm or C++. But a reasonable size, say 16 or 32 bits, will be fast. I've used it often when the target was Intel hardware with no floating point. +- are as fast as the corresponding integer operations and */ are a heck of a lot faster than emulated floating point. There are also things, such as RGB values, that cry out to be fixed point fractions rather than integers from 0 .. 255, or 0 .. 64, or whwatever.