Long word (4 byte boundry) requirement in C for structures

[eric eberhard]

It appear that 'C' requires that structures begin on an even 4 byte (long word) boundry. I am porting an application from AIX for which this is a pain. Is there any way in the world to set a compiler switch to disable this requirement? Any clues would be helpful!

[A. Clay Stephenson]

Normally, unless you need to access data from another environment, data alignment is a non-issue. If data alignment is critical is a multi-platform environment then you should be using XDR. Having said all this, here is your solution:

#pragma HP_ALIGN HPUX_WORD

Results in int and float types being halfword aligned (two-byte aligned), doubles being word aligned (four byte aligned), and all structs being
at least halfword aligned. This is the default for the Series 300/400 computer.

#pragma HP_ALIGN HPUX_NATURAL_S500

Results in doubles being word aligned. This is the default for the Series 500 computer.

#pragma HP_ALIGN HPUX_NATURAL

Results in native alignment for the HP 9000 workstations and servers. The int and float types are word aligned, doubles are double-word
aligned (8-byte aligned), and structs may be byte aligned depending upon the data types used within the structure.

#pragma HP_ALIGN NATURAL

Results in a superset of the above. Uses native alignment provided by HPUX_NATURAL, all structs and unions are at least halfword aligned, and
DOMAIN bit-field mapping is used. (See Chapter 2, "Storage and Alignment Comparisons," in the HP C/HP-UX Programmer's Guide for details
regarding Domain bit-fields.)

#pragma HP_ALIGN DOMAIN_NATURAL

Similar to NATURAL except long doubles are only 8 bytes long (treated as doubles).

#pragma HP_ALIGN DOMAIN_WORD

Similar to HPUX_WORD, with the following exceptions: long doubles are only 8 bytes long (treated as doubles) and DOMAIN bit-field mapping is
used. Refer to Chapter 2, "Storage and Alignment Comparisons," in the HP C/HP-UX Programmer's Guide for detailed information on Domain
bit-fields.

#pragma HP_ALIGN NOPADDING

Causes all structure and union members that are not bit-fields to be packed on a byte boundary. It does not cause crunched data packing, where
there are zero bits of padding. It only ensures that there will be no full bytes of padding in the structure or union.

Accessing Data with the HP_ALIGN Pragma

The HP_ALIGN pragma isolates data structures that are not naturally aligned for PA-RISC systems.

References to non-natively aligned data often results in poorer run-time performance than references to natively aligned data. Natively aligned data is
often accessed with a single load or store instruction. Non-natively aligned data must be accessed with one or more load and store instructions.

in addition, if you only need this for a limited section of code you can do something like this:

#pragma HP_ALIGN HPUX_WORD PUSH

This sets the alignment to HPUX_WORD and pushes the current setting onto a stack for later retrievel via

#pragma HP_ALIGN POP

All of this is available in your Online Help.

[Hartmut Lang]

It's not "C" that requires a specific alignment of data structures. It is the pair of processor/compiler which defines, the "best" layout for your C data structures. If your system (processor, memory) only allows physical memory access to long word addresses, the fastest way to access a structure in memory is, to allign it to these long word boundary. But on other systems the fastest way could be word or even byte boundary.

Most of the compilers allow to change this default alignment and padding (adding spaces between members of a struct). But generally this will result in longer code and execution time.

See Clays posting how to change aligment using HPs native compilers.
For the GNU compiler see "Specifying Attributes of Variables"
http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_5.html#SEC101

Hardy

[Gregory Fruth · Accepted solution]

Perhaps the "cc +u" option will be useful. From
the man page:

+unum
Allow pointers to access non-natively aligned
data. This option alters the way that the
compiler accesses dereferenced data. Use of
this option may reduce the efficiency of
generated code.
...

However, this sort of thing is always tricky. You
really would be better off using XDR, or using
your own byte-level manipulations (assuming you
know the memory layout of the original data).

Good luck!

[eric eberhard]

Thank you everyone for the help. I tried the #pragma first and had very strange problems. The compiler started enforcing some very weird rules regarding function declaration. Our code is in places 20 years old and old functions are written the old way:

void func(arg1,arg2)
int arg1;
int arg2;

Yet new programs that use them
may declare them:

void func(int arg1,int arg2);

With the pragma statement (any of them) this became an error and things would not compil:

error 1584: Inconsistent type declaration: func

Without the pragma these compil and work properly. The application is 181224 files in who knows how many directories and all with sccs. I was unwilling to go "fix" all these. I tried many different ANSI switches to no avail.

The suggestion to use the compiler switch "-n1" however worked perfectly and does not have this weird declaration problem and my application at first blush is working properly. It will take weeks to actually test it completely and I will have other questions!

[Bill Thorsteinson]

There are a few tools that will go through your old code and provide proper function prototypes. I don't have a handy reference as I haven't worked in C for a while.

K&R have documented the problem you ar running into with structures. sizeof(struct) is allowed to be different than the sum of sizeof(field) making up the structure, and offset of a field is not necessarily the sum of the sizes of the preceding fields making up the structure. If memory is not an issue, there should be a pragma to let the compiler align stucture fields on machine boundaries. This can be a harware performance issue.

If you can restructure your structures, try placing the fields in order by size with largest fields first. This will make the structures much more portable and efficient.