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: sampson@nosc.mil (Charles H. Sampson) Subject: Re: Fortran's Equivalence Date: 1997/04/08 Message-ID: <1997Apr8.155111.26714@nosc.mil>#1/1 X-Deja-AN: 231570649 Sender: news@nosc.mil References: <333840D1.7B12@cae.ca> <3349165C.3B93@cae.ca> Organization: Computer Sciences Corporation Newsgroups: comp.lang.ada Date: 1997-04-08T00:00:00+00:00 List-Id: In article <3349165C.3B93@cae.ca>, Viqar Abbasi wrote: > ... > >My original reason for this post was because when I received the code, >it used address clause overlays. However, on my GNAT 3.07 for SGI, the >overlaying didn't work (or at least, that particular code have the >wrong results). So, I added a routine for bit swapping, (localizing the >effect of changing machines to that one small routine), and then >proceeded with Unchecked_Conversion. Later, when I downloaded GNAT >3.09, I found that it offered a whole new spectrum of address clause >flexibility. A quick test showed me that the old address clause overlay >would work. So, I thought I'd ask about the "preferred method" to do >something which I knew is dangerous. (And actually, I've never used >EQUIVALENCE in a Fortran program... But I knew about it. :) > Great! An actual example of my repeated claim that the behavior of erroneous constructs can change from one version of a compiler to the next. Admittedly, from your point of view this change was an improve- ment, but it was a change nonetheless. > >record My_Record is > A: some_type; > B: some_other_type; > C: still_another_type; >end record; >for My_Record_Type'Size use 32; >for My_Record_Type use > record > A at 0 range 0 .. 14; > B at 0 range 15 .. 24; > C at 0 range 25 .. 31; > end record; > >Does "range 0 .. 14" mean the Most Signicant Bits? Or does it mean >"Left most bits"? This will clearly have an impact on my overlays. If >I'm going to move bits arouund, then I don't want to have to change the >record representation clauses... Will I be able to avoid it, by >only changing my bit-manipulation routine, depending on my machine? The bit order depends on the compiler. If you want to do the ex- tra work, you can code your record representation clauses to depend on one or more constant objects which you then set to appropriate values when transporting. Charlie