RE: [avr-gcc-list] string initialization using and { }

Compiling the following code: /* ... */ int main() { char test1[] = abd; char test2[] = { 'a', 'b', 'd', '\0' }; /* ... */ } shows this: char test1[] = abd; 8c0: 80 91 00 01 lds r24, 0x0100 8c4: 90 91 01 01 lds r25, 0x0101 8c8:

Re: [avr-gcc-list] string initialization using and { }

Zoran Rilak wrote: I can't find an explanation ... why there should be a difference in the generated code for string vs. array-of-chars initializers. If you declare a string and then use it as an initializer for an array of characters, the compiler will arrange for the string to be stored

Re: [avr-gcc-list] string initialization using and { }

Stu Bell wrote: [The compiler] stores the string constant in flash and then copies it into the stack ... The string is stored in flash only to initialize the string variable in RAM. It is copied from RAM to the automatic variable on the stack. It is important to understand that using the

Re: [avr-gcc-list] Bloat after upgrade to 1.6.5

On Tue, 26 May 2009 06:19:07 +0200 (MET DST) j...@uriah.heep.sax.de (Joerg Wunsch) wrote: Dmitry K. dm...@marine.febras.ru wrote: You can apply the Avr-libc patch #6718. It makes the EEPROM functions compact. (It is not checked with Xmega.) Xmega isn't supported currently anyway.

Re: [avr-gcc-list] Bloat after upgrade to 1.6.5

As Mark Litwack wrote: Xmega isn't supported currently anyway. What aspect(s) of Xmega isn't supported? Not supported by avr-libc? Or some recent versions of gcc? Or are you just referring to the EEPROM functions? Just the EEPROM functions, yes. -- cheers, Jorg .-.-.

Re: [avr-gcc-list] string initialization using and { }

If you declare a string and then use it as an initializer for an array of characters, the compiler will arrange for the string to be stored somewhere and then copy it to the array to perform the initialization. Should you need the string abd elsewhere in your program, the same copy might

Re: [avr-gcc-list] string initialization using and { }

Zoran Rilak wrote: I do not observe the string actually being copied to RAM: I suspect your problem lies outside of the scope of the information you've given us. Do *any* static variables with non-zero initializers have the correct value at run time? Graham.

RE: [avr-gcc-list] string initialization using and { }

Since it understands the concept of a string as a constant, it stores the string constant in flash and then copies it into the stack frame (your first example). Unfortunately, much worse than that. The constant initialiser is stored in initialised .data. I.e. it eats FLASH (as the .data

RE: [avr-gcc-list] string initialization using and { }

The constant initialiser is stored in initialised .data. I.e. it eats FLASH (as the .data initialiser), precious .data RAM, and of coursre the RAM in stack when actually used. I was playing with initialised local arrays a few days ago and found out, that avr-gcc performs this same

Re: [avr-gcc-list] Bloat after upgrade to 1.6.5

On Thursday 28 May 2009 01:58, Joerg Wunsch wrote: What aspect(s) of Xmega isn't supported? Not supported by avr-libc? Or some recent versions of gcc? Or are you just referring to the EEPROM functions? Just the EEPROM functions, yes. In addition, it is needed a clarification about the

Re: [avr-gcc-list] string initialization using and { }

Jan Waclawek konf...@efton.sk wrote: I would submit a request for enhancement, but was recently pointed out by the seasoned avr-gcc developers, that there's no reason in submitting RFEs without simultaneously providing a patch... Note that this behaviour is only a pessimization if you've got

Re: [avr-gcc-list] string initialization using and { }

Joerg, I am painfully aware of the consequence of avr-gcc sharing most of its codebase with a compiler primarily aimed at the big computers. IMHO it's a pity that the time and energy of volunteers did not went into the avr port of SDCC, which is maybe a more adequate, albeit certainly less