× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Data structure alignment
  • From: "Peter Dow" <pcdow@xxxxxxxxxxxxxxx>
  • Date: Thu, 12 Oct 2000 12:55:29 -0700

Thanks for the research Ken! Sounds like the compiler has some pretty
interesting logic to decide where to put data.


----- Original Message -----
From: "Sims, Ken" <KSIMS@SOUTHERNWINE.com>
To: <rpg400-l@midrange.com>
Sent: Thursday, October 12, 2000 11:39 AM
Subject: RE: Data structure alignment


> Hi Peter, Richard, Jon, et.al. -
>
> >How can one tell what boundary a data structure, or any other field for
> that
> >matter, is aligned on?
>
> For my test programs, I put debug(*yes) in the H-spec.
> I used eval [pointerfield] = %addr[field or data structure]
> followed by dump to get a nice readable output with the addresses of the
> fields and data structures.
>
> For the V4R4 RPG IV compiler, my observations are:
>
> 1. all data structures are currently 16-byte aligned, even ones containing
> just a simple character field.  However as Barbara has said, you shouldn't
> count on this always being the case for data structures that do not
contain
> pointers.
>
> 2. for multiple occurence data structures, only the first occurrence is
> necessarily 16-byte aligned.  If the data structure contains pointers, all
> occurrences are 16-byte aligned of course.  If a data structure contains
> float or integer fields and the ALIGN keyword is not used, there are no
gaps
> between occurrences and so those fields can be aligned in some occurrences
> and not aligned in other occurrences.  If the ALIGN keyword is used, there
> will be gaps between occurrences as needed so that all of the occurrences
> will start on the boundary needed to force alignment, but not necessarily
on
> a 16-byte boundary.
>
> 3. for individual fields, float and integer fields are aligned on the
> appropriate boundary for performance as expected.  Packed and zoned fields
> are not aligned in any particular way.  Interestingly, it appears that
> individual character fields are always aligned to the boundary of the
power
> of 2 greater than or equal to the length of the field, up to a maximum of
> 16-byte alignment!  (Character fields in a data structure just follow each
> other as expected.)  The order of fields in memory will be rearranged from
> the order specified in the program to take advantage of the gaps left by
> alignment.
>
> But again, one should not count anything of the things mentioned above
> (except pointer alignment) as being something that one can count on to
stay
> the same from release to release.
>
> Ken
> Southern Wine and Spirits of Nevada, Inc.
> Opinions expressed are my own and do not necessarily represent the views
of
> my employer or anyone in their right mind.
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.