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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2203a21a136b39cc X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Fortran's Equivalence Date: 1997/03/26 Message-ID: <5hbcdn$i1h@top.mitre.org>#1/1 X-Deja-AN: 228504218 References: <333840D1.7B12@cae.ca> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Date: 1997-03-26T00:00:00+00:00 List-Id: The requirements for poratability and speed might be opposing each other a little, and some balance might be required. One possible compromise is to use the Ada 95 SHIFT capababilities. To get at a bit string, shift it and AND it, similar to what the FORTRAN generated code is doing in this case. You are right, however, that address overlays are almost always faster in execution time than any operation in a HOL, unless the HOL optimizes the operation away. The portability problem comes in because the Ada-95 manual did not standardize a bit numbering in the word, nor does it standardize a pragma to tell which bit is zero in a portable manner. Had it done so, then about half of all bit field applications would have been portable using address overlays. As it is, true portability (without a changing global flag telling where bit one is), is difficult to accomplish without using specific operations (like SHIFT), which have effects on performance (both speed and logically overspecified algorithms).