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,b23661223cdab88a X-Google-Attributes: gid103376,public From: Pascal MALAISE Subject: Re: Representation clauses and records Date: 1997/12/17 Message-ID: <34979C4A.3C2D3D71@alphalink.com.au>#1/1 X-Deja-AN: 299382878 Content-Transfer-Encoding: 7bit References: <347000b1.4909762@news.geccs.gecm.com> <349646A2.1A013246@alphalink.com.au> <1997Dec16.061148.1@eisner> Mime-Version: 1.0 To: Kilgallen@eisner.decus.org.nospam Content-Type: text/plain; charset=us-ascii Organization: Alphalink Australia Newsgroups: comp.lang.ada Date: 1997-12-17T00:00:00+00:00 List-Id: Larry Kilgallen wrote: > > In article <349646A2.1A013246@alphalink.com.au>, Pascal MALAISE writes: > > When you declare your array of bytes/characaters, the compiler > > implements > > the array starting at any address. When you cast, the compiler will > > consider the new (integer) data as aligned and the processor will trap. > > Whether the compiler (for any language) assumes that such variables > are aligned depends on the quality of the compiler and what you have > told it. > > The DEC compilers for various languages on Alpha have many hooks for > indicating what assumptions should be made regarding alignment. The > result is to tune the generated code between that which presumes worst > case alignment and that which presumes best case alignment. Let's take an example: char buf[500]; int i; i = * (int*) buf; /* or &buf[x] */ The compiler will allocate i at a correct address (multiple of 4). But buff is often allocated at any address (probably to save stack space). The C cast will often be compiled in assembly by a load_int/store_int, the store generating the analigned access. As far as I know, this problem would not happen in full ADA because the instanciation of unchecked_conversion will be compiled as a call to something like memcpy, a procedure which does not make any assumption about alignment of arguments. We loose performance but gain reliability. Back to the debate, and thinking about it: What is the use of alignment clauses? The only one I can see is, by instance, when you declare an array of bytes/characters and intend to pass it by address to a procedure in another language which will assume that this address points to a more elaborated data structure (int, record...): type T1 is array (1..500) of CHARACTER; type T2 is record THE_ARRAY : T1; end record; for T2 use record at mod 4; end record; procedure C_CALL (A : in SYSTEM.ADRESS) pragma IMPORT (C, C_CALL, "c_call"); -- or pragma INTERFACE in C: void c_call (int *p); Without the alignment clause on T2, c_call may trap when using *p BTW, I don't know what we should expect from a "modern" ADA compiler about such representation clause: type T is record F1 : INTEGER; F2 : CHARACTER; F3 : INTEGER; end record; for T use F1 at 0 range 0 .. 31; F2 at 4 range 0 .. 7; F3 at 5 range 0 .. 31; end record; Should it refuse it, or generate byte accesses for F3? (Without the clause, of course, some gap would be generated between F2 and F3.) Practically speaking 1. it is more likely to have the "high" level data structure implemented in ADA, calling C and giving it by address and C taking in as a char*. So no need for alignment/representation clause. 2. we have C and ADA processes exchanging TCP messages, and in the message record types, we put longs first, then ints, then shorts, then bytes. We declare similar types in ADA and C and let each compiler manage to implement the stuff. Believe it or not, it works without clause in 99.99% of the cases. Compilers, even stupid (what I don't believe) have a similar logic. This approach appears to be the most practical and portable. My recomendation, based on ADA 83/C interfaces (DG, ULTRIX, DEC UNIX) would be: "Use representation clauses as a last option only", which mainly applies to all the stuff in chapter 13. -- Pascal MALAISE | E-mail: 52 Fletcher St | (priv) malaise@alphalink.com.au HAWTHORN EAST VIC 3123 | (prof) malaise@thomson.starway.net.au AUSTRALIA