Thread: 32 bit or 64 bit allignment ?! gcc options??

I am trying to read the man of gcc but I have not figured out what sort of problem I might have with data alignment for ints, doubles, structs and arrays.

Let's summarize in a few questions:
(1) I guess for a relatively recent 32bit Intel x86 , data alignment must be 32 bit for all ints, doubles, struct fileds, array elements or any other data. Because otherwise pthread_mutex_locking for multithreading data protection would be not sufficient to protect shared data? Is this a default option of the compiler? How would be this option changed?
(2) For a 64 bit more recent Intel do I have to require 32 or 64 bit alignment of all data? What is the default?
(3)
What if an array is shared but each single element is not shared
or a struct is shared but each single element is not shared. Example:
Thread 1 uses struct.field1 and a[0] while Thread2 uses struct.field2 and a[1]
What if my code does not use mutexes to protect these data cause they are not effectively shared? Is there some probability that the compiler does not align field1 and field2 or a[0] and a[1] so that I have errors?!

Please help me understand!
Thank you

oops.. part of the answer was probably given in the previous threads
http://cboard.cprogramming.com/showthread.php?t=105136
and http://cboard.cprogramming.com/showthread.php?t=104627
I will review it but I guess still part of my doubts will be left!!

As far as I know it's up to the compiler to align your variables in memory. By default, your compiler will align to WORD size. WORD is the largest number of bits that fits on your memory address bus. In a 32bit machine, that's 32bits, etc. So an int on your 32bit machine is 4bytes. All structs will be aligned to 4bytes.
As far as I know, 32bit programs will run just fine on 64bit machines. The CPU has no influence on how things are written to your struct. If you're using threads, they'll be compiled with the same option anyway, so it doesn't matter. When you have two different programs communicating via shared memory, you should align the struct to 64bit yourself to avoid problems when recompiling as 64bit in the future.

HTH,

QuantumPete

The answer very much depends on the actual processor architecture. If we take the ones I'm most familiar with, x86 and x86-64 [aka X64], then the processor has distinct instructions for 8, 16, 32 and 64-bit [and SSE has 128-bit data width - and 80-bit extended precision floating point and some other even more obscure ones] to read & write data (and almost all read-modify-write in one instruction has the same options for width, e.g. add 4 to memory at location x - which reads memory at x, then adds 4 to the result of the read and writes the new value back). So your example should be fine in this case - if processor1 has cached the value of struct.field1, then the write from processor2 will send a signal to P1 (and any/all other processor(s) in the system) to invalidate that cache-entry.

Other processor architectures may not support this full range - e.g. MIPS [afaik] only supports 8 and 32-bit read/write operations, so a 16-bit operation would need to be done in a multi-step sequence: Read 32 bits, mask of (and save) the 16 that we don't want, update the 16 that we are interested in, put the saved bits back in, and store the 32-bit value. This mechanism obviously will not work with SMP systems where you share 16-bit data within a 32-bit word, because the saved data may change without the current processor noticing.

As to alignment, the standard alignment is to always align structure members to their own size, e.g. 32-bit integers are aligned to even 32-bits. In some processors architectures, failure to do so will lead to a trap or fail. In others (e.g. all x86-related processors), it is "only" a performance penalty to perform unaligned memory accesses.

So unless you specifically ask for other alignments, you should have the "align to its own size". Note that a struct that only contains 16-bit data members will thus be aligned to 16-bits. A struct that has one 32-bit and one 16-bit member will have an alignment of 32.

--
Mats