Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

NIOS II Structure Casting w/ Opt. (-O3)

Altera_Forum
Honored Contributor II
1,340 Views

I recently enabled optimization on my NIOS II software (custom telnet server + webserver) and I'm experiencing unexpected behavior. I suspect memory corruption and alignment issues, but I can't seem to get this resolved. The software does work reliably when optimization is disabled. 

 

One of my issues is when type casting a data word (unsigned int) to a bit-wise data structure (word aligned) as shown below. This is performed on the stack, so I'm not sure what the problem is. The register value is valid (val), and so is the bitfield when manually masking & shifting. I also verified the structure is packed (no padding, sizeof(version_reg_t)=4), and adding the following "__attribute__((packed, aligned(4)))" did not fix this issue. 

 

typedef struct{ 

uint32_t ver_build_rev :8; 

uint32_t ver_fpga_id :8; 

uint32_t ver_major_rev :8; 

uint32_t ver_minor_rev :8; 

}version_reg_t; 

 

uint32_t val = IOWR_32DIRECT(0, VERSION_ADDR_OFFSET); 

version_reg_t* p_reg = (version_reg_t*)&val; 

 

In my makefile, I'm only using the following APP_MAKEFILE_FLAGS: 

--set APP_CFLAGS_OPTIMIZATION -O3 

 

Any help would be appreciated.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
538 Views

Look at the assembler code generated for your code. 

 

I had a case on an x86 where bit-field access resulted in byte-based assembly instructions, even though the bit-field is described using integers. 

 

In your case, since each bit-field is actually a byte, it might be less ambiguous (in the sense of undefined compiler operation) to use an array of bytes. You can use a union to make the array accessible as either a single integer or four single byte fields. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
538 Views

Write valid C! - see 'strict aliasing'. 

The compiler is allowed to (and will) reorder memory accesses if the types differ (and aren't 'char') even if it is obvious from the source code that they refer to the same physical memory. 

If you use a 'union' then you'll get the code you expect. The compiler will also sometimes use shifts and optimise away the memory access itself. 

 

I'd not thought that int:8 might give a byte-sized item that the compiler doesn't have to assume might alias all other C types.
0 Kudos
Reply