Forum Discussion
Altera_Forum
Honored Contributor
12 years agoMy conclusions about the extra ands with 0xff were that they happened when gcc 'found' the value in a register and assumed that this was the result of an arithmetic operation so needed masking with 0xff.
I think volatile is implemented by forcing an extra memory load - and that is promoting the 'unsigned char' to 'int' - hence the mask. The ldio offsets might be similar to the issues I had with 'small data'. Not difficult to fix once you've worked out the code paths involved. For my code the extra instructions were a performance problem. I used quite a few asm volatile ("":::"memory") lines (which gcc has to assume might modify all of memory) not only to replace volatile, but also to cause values to be read early (eg before an 'if' when they are only needed in the 'then' clause) to avoid stall cycles following memory loads. If might have been easier to write the code directly in assembler - but that is error prone even for less than 1000 instructions. FWIW if we'd had to wait for Altera to fix the compiler to support structures in the small data segment, I suspect we'd still be waiting and wouldn't have the product we shipped several years ago. Fortunately I was able to fix gcc myself so we didn't have to raise a support request through our FAE. We don't have the resources to chase Altera to accept the fix. This reminds me of my dealings with major real-time OS manufacturer a few years back. I got our system running by re-implementing some functions and patching in jump instructions to the new version over the first instructions of the old copy (as well as some smaller patches). In spite of raising these issues with their UK support, I finally discovered that the only way any support issues would get fixed in the next release was if the support group had themselves had to issue a fix. Once I'd generated the patch, we didn't need a fix from support. Any one else trying to do the same thing would though.