Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Jan Waclawek <wek@ef...> - 2011-11-28 10:38:10
Recently, Philipp Klaus Krause started a discussion (and implementation) of named address spaces into SDCC.
Moreover, in the last few weeks, a significant progress has been achieved in implementing certain aspects of named address spaces into avr-gcc.
However, the problem of explicit placement of string literals into a given address space has not be addressed. I also could not find a guideline for them in the existing standard proposals.
The current state is, that in SDCC (at least for the mcs51 target) string literals are implicitly placed into __code, and there is no way to place the string literal in other memory space. In avr-gcc, string literals are implicitly placed into RAM, and for placing them into program memory (FLASH), in the standard avr-libc library a macro is provided (PSTR() in <avr/pgmspace.h>), which through a bracketed comma-operator expression generates an inicialized local variable into FLASH and returns the pointer to it.
I would like to discuss a unified approach, which could be possibly implemented in the future. I have two proposals (assuming a named space called "space1", and a function MyPrintf(space1 char *) ):
MyPrintf((space1 char *)"Hello world");
While the second form has the syntax of typecast, in this particular case (applied to string literal) it would have also a modified semantics in that it would determine the placement of the string literal.