Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

gcc alignment

I'm surprised. I have a C++ code that fills a char array and there seems to be an alignment problem with g++. See below: 

char* response = new char;
response = 0;
unsigned int* dataSize = (unsigned int*)&response;
*dataSize = 0x08070605;
The array elements, after dumping: 

response: 5
response: 6
response: 7
response: 8
response: 0
response: 0
...
Is there something wrong with my code? I have always worked in this way without any problems. Should I fill the array using memcpy?

6 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Complementing, I'm using nios2-linux-20100621.tar distribution without mmu (branch test-nios2). I've tested with pre-built toolchain (nios2gcc-20080203.tar.bz2) and with my build of gcc (nios2-linux/toolchain-build). The results are the same.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Well, after a little search, I found that this behavior is "by design", and not a gcc bug. In x86 processors, the code works fine, because it's possible "to access" integers at any address. In nios2 apparently not.

    Please, can someone tell me what is the correct way to fill an array without to worry about alignment issues?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Is there a reason you need to fill a char array with ints? Just filling with chars might make your problem go away.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Dear Donq

    "response" is not just an array of chars, is a buffer that I send using TCP, and I want to fill it with data according to defined in protocol (integers, floating points, bytes and strings must be "embedded" in the array).

    Thanks
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    It could be a good idea to split all your data in chars before filling the buffer. The code will be a bit slower, but at least you won't depend on big/little endian problems and other subtleties.

    AFAIK the behaviour of C code writing ints in a char buffer isn't defined, and can change from one platform to another, or even from a compiler to another (and, with a little help from Murphy's law, maybe even from a version of a compiler to another).

    I'm not even sure that defining your packet data as a struct will give predictable results, but I may be wrong on this one.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    From the manual:

    --- Quote Start ---

    STW

    Description

    Computes the effective byte address specified by the sum of rA and the instruction's signed 16-bit immediate value. Stores rB to the memory location specified by the effective byte address. the effective byte address must be word aligned. If the byte address is not a multiple of 4, the operation is undefined.

    --- Quote End ---

    Seems that it is not gcc doing this. The compiled code actually uses the value pointer+1 to do a STW (store word) instruction. It is the NIOS instruction set that aligns the store word instruction (it appears to truncate the low 2 bits of the store address for STW, but the manual says "undefined", meaning that it might be different in a different version of the processor).

    No way around it. To store at byte addresses, you are going to have to use bytes, or use a different processor, or write your own routine for storing words at byte addresses (another version of "using bytes");