Re: Aligning record components

Re: Aligning record components

[Robert Dewar]

kgamble says

<<I do not know why GNAT does not allow 2-byte alignments. There are still

plenty of 16-bit target machines that Ada supports.

>>

Of course GNAT supports 2-byte alignments on a target where 2-byte alignment is natural. Alignment
requirements are highly target dependent!

GNAT does allow misaligned integers, because this is a widely used feature.

An Ada 95 compiler is not required to allow *any* misalignment, and GNAT does not
bother to allow misaligned floating-point for two reasons

One techncail

a) the cost of unaligned fpt access is MUCH higher than unaligned integer access
on a typical machine

One non-techncial

b) none of our customers have ever indicated a desire for this feature

It would not be that hard to do, but would be non-zero work. You could of course build a new configuration file with diminished alignment requirements.

Aligning record components

[kgamble]

I am porting Ada code from a 16-bit machine to a PC. The original code had
record structures that had components aligned on 16-bit boundaries. The
components were 16 and 32 bit integers and 32 bit floats. I need to
maintain the exact alignments on the new PC target. There does not appear
to be a way to do this using the GNAT compiler without resorting to record
representation clauses. I understand the benefits of using such clauses,
but the scope of the work to create thousands of these component clauses is
significant, so I am looking for a work around.

If I could force 2-byte alignments, then my problem would be solved.
However, GNAT only allows 4-byte alignments. In the following data
structure I would need to see components at positions at (0,2,6,10,14).
What GNAT gives is (0,2,8,12,16), or by using pragma pack (0,2,6,12,16). It
is interesting that the pack version does align 32-bit integers correctly,
but has no affect on 32-bit floats. 

   type rec_type is
      record
          I16: Integer_16;
          I32: Integer_32;
          J32: Integer_32;
            f: float_32 ;
            H: float_32;
      end record;

I understand that relying on implicit characteristics of a compiler is not
good for portability. But a required goal in the port is to make minimal
changes to the original source code when doing the port. Fixing the
original source code to use representation clauses is not possible at this
time. 

I do not know why GNAT does not allow 2-byte alignments. There are still
plenty of 16-bit target machines that Ada supports.  

Re: Aligning record components

[Tucker Taft]

kgamble (kgamble@ricochet.net) wrote:
: I am porting Ada code from a 16-bit machine to a PC. The original code had
: record structures that had components aligned on 16-bit boundaries. The
: components were 16 and 32 bit integers and 32 bit floats. I need to
: maintain the exact alignments on the new PC target. There does not appear
: to be a way to do this using the GNAT compiler without resorting to record
: representation clauses. I understand the benefits of using such clauses,
: but the scope of the work to create thousands of these component clauses is
: significant, so I am looking for a work around.

: If I could force 2-byte alignments, then my problem would be solved.
: However, GNAT only allows 4-byte alignments. In the following data
: structure I would need to see components at positions at (0,2,6,10,14).
: What GNAT gives is (0,2,8,12,16), or by using pragma pack (0,2,6,12,16). It
: is interesting that the pack version does align 32-bit integers correctly,
: but has no affect on 32-bit floats. 

Have you tried specifying the alignment of your scalar types, such as via:
   for Integer_16'Alignment use 2;

This might cause GNAT to lay out the records as you wanted.

:    type rec_type is
:       record
:           I16: Integer_16;
:           I32: Integer_32;
:           J32: Integer_32;
:             f: float_32 ;
:             H: float_32;
:       end record;

: I understand that relying on implicit characteristics of a compiler is not
: good for portability. But a required goal in the port is to make minimal
: changes to the original source code when doing the port. Fixing the
: original source code to use representation clauses is not possible at this
: time. 

: I do not know why GNAT does not allow 2-byte alignments. There are still
: plenty of 16-bit target machines that Ada supports.  

GNAT probably uses 4-byte alignment by default since it is more efficient
on modern x86 chips.  However, the alignment clause (exemplified above)
is one way to override this choice, at least for you own scalar types.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA