Re: Using Named Address spaces.
Georg-Johann Lay <[email protected]>
| Newsgroups | gmane.comp.hardware.avr.gcc |
|---|---|
| Message-ID | <[email protected]> |
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