Re: [avr-gcc-list] Using Named Address spaces.

[Georg-Johann Lay]

Thomas, George schrieb:
> Some of the doubts about the patch are :
>
> 1. If __flash5 is used then for placing the code we get only 0x50000 
> to the rest of the flash for storing code (.text) . How can we make use 
> of the space before in a case where __flash1 - 4 are absent ?

You can also use a home-brew linker script to arrange for this.

Currently, the default linker script does not support __flashN and 
__memx, thus caught by *(.progmem*).  Cf. Binutils PR14406.

avr-tool users typically don't give feedback to the developers during 
the development stage.  Moreover, one linker script cannot model any 
imaginable memory layout optimally.  There are proposals for default 
scripts that work reasonably[tm] with reasonable[tm] memory layouts. 
But: The more uncommon the layout is, the more likely you want an own 
script for optimal control.

> [...]
> Adding my understanding of memx (courtesy :
> http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html )
>
> The __memx qualifier can be use to load and access variables in 24 bit
> address spaces which linearizes flash and RAM. If the high bit of the

Oops, a typo.  Must read "address space".

> address is set, data is read from RAM using the lower two bytes as RAM

Caveat: It might also read from I/O etc. and then cause side effects.

> address. The loading from flash works by making use of the ELPM
> instruction available in AVR.

Notice:  If there is no ELPM, LPM is used.

> How it does this ?
> After loading the addresses to the registers r30, r31 (Z) and highest
> bits in r21 the function is called to load the value to the location
> r22, r23.

;; This and similar function are non-ABI.
> 00000238 <__xload_2>:
>  238:   57 fd           sbrc    r21, 7
>  23a:   05 c0           rjmp    .+10            ; 0x246 <__xload_2+0xe>
>  23c:   5b bf           out     0x3b, r21       ; 59
>  23e:   67 91           elpm    r22, Z+
>  240:   77 91           elpm    r23, Z+
;; Clearing Z indicates RAMPZ is also used for RAM accesses, i.e. XMEGA.
;; GCC assumes RAMPZ is always zero if it might also be used for RAM.
;; This means (inline) assembler and libraries must also follow this.
;; No caveat for GCC because __memx is new feature :-)
>  242:   1b be           out     0x3b, r1        ; 59
>  244:   08 95           ret
>  246:   61 91           ld      r22, Z+
>  248:   71 91           ld      r23, Z+
>  24a:   08 95           ret
>
> Uses a combination of RAMPZ (0x3b) and Z (r30, r31) for doing the work.
> The sbrc instruction checks if the location is a program memory or RAM.
> (checking high bits)
>
> Also .progmemx.data is the section the data falls into (So as per

This changed with GCC PR55897.  Caveat: This is not yet mentioned in the 
4.7 release caveats.  EW could please add it; me won't be able to change 
the release notes for the next weeks or months.

> current linker scripts goes in flash) As far as I understand __memx is a
> qualifier that is intended to be used primarily as a pointer to access
> data rather than to store data. (unification of RAM and FLASH)

Yes.  Using __memx without const will throw an error. Same for any other 
non-generic, AVR-specific address space.

Nitpick: A qualifier /is/ not a pointer, it can be used no /qualify/ a 
pointer.  Moreover, address space qualifiers can locate data in 
non-local, static storage, i.e. pick (input sections) for objects.  This 
won't work with GCC's section attribute (GCC PR53372).

Johann