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

This is a discussion on 32 bit or 64 bit allignment ?! gcc options?? within the C Programming forums, part of the General Programming Boards category; I am trying to read the man of gcc but I have not figured out what sort of problem I ...

  1. #1
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251

    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
    memory granularity of the processor
    and mutex necessity
    I will review it but I guess still part of my doubts will be left!!
    Last edited by mynickmynick; 07-28-2008 at 11:12 AM.

  2. #2
    Alessio Stella
    Join Date
    May 2008
    Location
    Italy, Bologna
    Posts
    251
    Can it happen at point (3) the following:
    field1 and field2 have size x while the CPU 2x (for instance x=32bits and CPU 64 bits)
    Thread1 reads struct.field1 (but also field2 as a side effect)
    Thread2 reads struct.field2
    Thread2 writes struct.field2
    Thread1 writes struct.field1 OVERWRITING struct.field2 with its old value??!!

  3. #3
    Technical Lead QuantumPete's Avatar
    Join Date
    Aug 2007
    Location
    London, UK
    Posts
    894
    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
    "No-one else has reported this problem, you're either crazy or a liar" - Dogbert Technical Support
    "Have you tried turning it off and on again?" - The IT Crowd

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. If the RGB color is (64, 64, 255), change it to (64, 255, 64).
    By Grayson_Peddie in forum C# Programming
    Replies: 2
    Last Post: 06-14-2003, 05:26 PM
  2. How do I print 64 bit unsigned integer in hex?
    By electrolove in forum C Programming
    Replies: 7
    Last Post: 02-11-2003, 12:43 PM
  3. 64 bit variables
    By Yawgmoth in forum C Programming
    Replies: 11
    Last Post: 12-19-2002, 01:55 PM
  4. 16 bit or 32 bit
    By Juganoo in forum C Programming
    Replies: 9
    Last Post: 12-19-2002, 07:24 AM
  5. 64 bit
    By stormbringer in forum C Programming
    Replies: 2
    Last Post: 10-29-2002, 06:51 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21