Aligning record components 
Author Message
 Aligning record components

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.  



Sat, 25 Dec 1999 03:00:00 GMT  
 Aligning record components

: 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.

--

Intermetrics, Inc.  Burlington, MA  USA



Sat, 25 Dec 1999 03:00:00 GMT  
 Aligning record components

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.



Sat, 25 Dec 1999 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Non byte-aligned components in GNAT rejected

2. elisp to align colons in a record - improved version

3. ALIGN and ALIGNED words

4. ABC - Prime Record in multi component key ( C5002 )

5. Memory representation of variable length record components

6. aliased discriminant record components

7. Finalization of record components which are tasks

8. constant record components in Ada

9. Record component positions always constant?

10. Question about anonymous arrays as record components

11. record component selector in init

12. Record rep specs for private components

 

 
Powered by phpBB® Forum Software