Re: Representation clauses and records

[Pascal MALAISE <malaise@alphalink.com.au>]

Larry Kilgallen wrote:
> 
> In article <349646A2.1A013246@alphalink.com.au>, Pascal MALAISE <malaise@alphalink.com.au> 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