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: mheaney@ni.net (Matthew Heaney) Subject: Re: Fortran's Equivalence Date: 1997/03/29 Message-ID: #1/1 X-Deja-AN: 229332227 References: <333840D1.7B12@cae.ca> <5hbcdn$i1h@top.mitre.org> Organization: Estormza Software Newsgroups: comp.lang.ada Date: 1997-03-29T00:00:00+00:00 List-Id: In article <5hbcdn$i1h@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) wrote: >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. No. Do not use shift - use a record with a representation clause, and convert it using Unchecked_Conversion. Using shift is for languages that lack Ada's powerful abstraction features. (Even in C you can do use a bit field.) >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. Using Unchecked_Conversion will very likely generate NO code, and it's infinately safer than an address overlay. People have been making claims about "HOL inefficiency" since the first compilers came out 40 years ago. How do you know, because greater semantic information is available to the Ada compiler, that equivalent structures aren't more efficient in Ada (proudly HOL) than in a lower-level language? >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). What's wrong with the Bit_Order attribute? Can't you use that to portably specify record representations? It's all very theoretically interesting about what would have allowed portability using overlays, but since you should never use address overlays to change representation, then such conversation is just idle speculation, eh? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271