__memx - initializer element is not computable at load time

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I've tried to use new feature of avr-gcc "“ named address spaces. For example the following code:

const __flash char *x=PGM_STR("Test");

works fine. But I want to create a structure which members can point into FLASH or SRAM memory, so I changed __flash to __memx:

const __memx char *x=PGM_STR("Test");

but this gives me an error - initializer element is not computable at load time. Why it is not computable at load time? To me there is no difference between two initializers. The macro PGM_STR expands as follows:

#define PGM_STR(X) ((const __flash char[]) { X })

So, can I define load-time constants using __memx?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure about this, but I think its due to the PGM_STR macro saying to store it in __flash, while __memx is an entirely different address space.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It’s true. But when I specify __memx address space, the string will probably land in SRAM, not in FLASH memory? I can’t test it, because the code:

#define PGM_STR(X) ((const __memx char[]) { X })
const __memx char *x=PGM_STR("Test");

don’t compile in Atmel Studio:

Error	1	assembling 24-bit address needs binutils extension for hh8(__compound_literal.0)

gcc 4.7.2, Atmel toolchain 3.4.2.992 (3.4.2.1002). So it seems that the Atmel toolchain has old binutils.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The __memx stuff is IMHO far from being mature. Ideally, it should support seamless casting pointers from any other address space (see generic pointers in other 8-bit compilers, e.g. SDCC), but given the state of affairs, it is unlikely it will happen in foreseable future.

The root of the problem is in the compiler - it emitted a warning (which I assume you converted to error using the respective command-line option) at the time when gas/ld was not able to assemble/link the hh8() directive. While binutils have been fixed since then, the warning (and also the commented-out directive, making it completely unusable) remained...

  18               	.global	x
  19               		.data
  22               	x:
  23 0000 0000      		.word	__compound_literal.0
  24               		.warning	"assembling 24-bit address needs binutils extension for hh8(__compound_literal.0)"
  25 0002 00        		.byte	0	 ;  hh8(__compound_literal.0)

Meantime, as suggested in https://www.avrfreaks.net/index.p... and subsequent, you could try the avr-gcc 4.8 bundle from http://sourceforge.net/projects/... (I did not try, so I can't report).

JW