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,6eeec5ea37e964f0 X-Google-Attributes: gid103376,public From: Brian Nettleton Subject: Re: Representation clauses and records Date: 1997/11/21 Message-ID: <3475F02C.5585B1B6@aonix.com>#1/1 X-Deja-AN: 291409200 Sender: news@sd.aonix.com (USENET News Admin @flash) References: <347000b1.4909762@news.geccs.gecm.com> Reply-To: bn@sd.aonix.com X-Nntp-Posting-Host: stout To: brian.orpin@gecm.com Organization: Aonix Newsgroups: comp.lang.ada Date: 1997-11-21T00:00:00+00:00 List-Id: Brian Orpin wrote: > I have played with this before but never fully understood it. Now I need > to understand it and my colleagues and I have had many hours discussing > it. The compiler being used is Ada 83. > > The question is simple; when declaring a representation clause for a > record there is an optional alignment clause using 'mod at'. What effect > does this have on the component representation clause and how does this > relate to the storage size of the system? > > Having read the LRM I get the impression that it is to do with word > boundaries and alignment but I do not understand the implications of > using different values for the 'at mod' statement. > > Any explanations gratefully received. This is not homework :-)) > > -- > Brian Orpin (These thoughts are my own ......... for once!) > brian.orpin@ge_XXX_cm.com or BrianOrpin@Big_XXX_foot.com > http://www.borpin.demon.co.uk/ **Anti-spam reply-to remove X** Alignment is an important consideration for the representation of data items at the hardware level. Many (most?) hardware architectures/implementations (ie. Intel Pentium, PowerPC, SPARC, etc.) have performance penalties associated with mis-aligned data items. Loading a word into a register for a mis-aligned address usually involves either extra instructions or extra hardware cycles. This means that there are different space/time tradeoffs for different alignments. Consider (simple example with 32 bit word assumption): type Space_Optimized_Array_Element is record Field1 : Integer; Field2 : Boolean; end record; for Space_Optimized_Array_Element use record at mod 1; Field1 at 0 range 0 .. 31; Field2 at 4 range 0 .. 8; end record; type Space_Optimized_Array_Type is array (1..2) of Space_Optimized_Array_Element; pragma Pack(Space_Optimized_Array); -- Ada83 method to assure space opt. Space_Optimized_Array : Space_Optimized_Array_Type; And: type Time_Optimized_Array_Element is record Field1 : Integer; Field2 : Boolean; end record; for Time_Optimized_Array_Element use record at mod 4; Field1 at 0 range 0 .. 31; Field2 at 4 range 0 .. 8; end record; type Time_Optimized_Array_Type is array (1..2) of Time_Optimized_Array_Element; Time_Optimized_Array : Time_Optimized_Array_Type; Layout of Space_Optimized_Array and Time_Optimized_Array: Offset (in bytes) Data Item ---------------- ---------- 0 Space_Optimized_Array(1).Field1 4 Space_Optimized_Array(1).Field2 5 --misaligned Space_Optimized_Array(2).Field1 9 Space_Optimized_Array(2).Field2 0 Time_Optimized_Array(1).Field1 4 Time_Optimized_Array(1).Field2 8 --aligned Time_Optimized_Array(2).Field1 12 Time_Optimized_Array(2).Field2 Now the Space_Optimized_Array should be 10 bytes in length and accessing Field1 may take more CPU cycles, and Time_Optimized_Array is generally 16 bytes in length, but accesses to Field1 should always take a minimum number of CPU cycles. -Brian Nettleton Aonix