3.19.6.1 EIND and Devices with More Than 128 Ki Bytes of Flash ¶

Pointers in the implementation are 16 bits wide. The address of a function or label is represented as word address so that indirect jumps and calls can target any code address in the range of 64 Ki words.

In order to facilitate indirect jump on devices with more than 128 Ki bytes of program memory space, there is a special function register called EIND that serves as most significant part of the target address when EICALL or EIJMP instructions are used.

Indirect jumps and calls on these devices are handled as follows by the compiler and are subject to some limitations:

• The compiler never sets EIND.
• The compiler uses EIND implicitly in EICALL/EIJMP instructions or might read EIND directly in order to emulate an indirect call/jump by means of a RET instruction.
• The compiler assumes that EIND never changes during the startup code or during the application. In particular, EIND is not saved/restored in function or interrupt service routine prologue/epilogue.
• For indirect calls to functions and computed goto, the linker generates stubs. Stubs are jump pads sometimes also called trampolines. Thus, the indirect call/jump jumps to such a stub. The stub contains a direct jump to the desired address.
• Linker relaxation must be turned on so that the linker generates the stubs correctly in all situations. See the compiler option -mrelax and the linker option --relax. There are corner cases where the linker is supposed to generate stubs but aborts without relaxation and without a helpful error message.
• The default linker script is arranged for code with EIND = 0. If code is supposed to work for a setup with EIND != 0, a custom linker script has to be used in order to place the sections whose name start with .trampolines into the segment where EIND points to.
• The startup code from libgcc never sets EIND. Notice that startup code is a blend of code from libgcc and AVR-LibC. For the impact of AVR-LibC on EIND, see the AVR-LibC user manual.
• It is legitimate for user-specific startup code to set up EIND early, for example by means of initialization code located in section .init3. Such code runs prior to general startup code that initializes RAM and calls constructors, but after the bit of startup code from AVR-LibC that sets EIND to the segment where the vector table is located.

  #include <avr/io.h>
  
  static void
  __attribute__((section(".init3"),naked,used,no_instrument_function))
  init3_set_eind (void)
  {
    __asm volatile ("ldi r24,pm_hh8(__trampolines_start)\n\t"
                    "out %i0,r24" :: "n" (&EIND) : "r24","memory");
  }
  

  The __trampolines_start symbol is defined in the linker script.

• Stubs are generated automatically by the linker if the following two conditions are met:
  • The address of a label is taken by means of the gs modifier (short for generate stubs) like so:

    LDI r24, lo8(gs(func))
    LDI r25, hi8(gs(func))
    

  • The final location of that label is in a code segment outside the segment where the stubs are located.
• The compiler emits such gs modifiers for code labels in the following situations:
  • Taking address of a function or code label.
  • Computed goto.
  • If prologue-save function is used, see -mcall-prologues command-line option.
  • Switch/case dispatch tables. If you do not want such dispatch tables you can specify the -fno-jump-tables command-line option.
  • C and C++ constructors/destructors called during startup/shutdown.
  • If the tools hit a gs() modifier explained above.
• Jumping to non-symbolic addresses like so is not supported:

  int main (void)
  {
      /* Call function at word address 0x2 */
      return ((int(*)(void)) 0x2)();
  }
  

  Instead, a stub has to be set up, i.e. the function has to be called through a symbol (func_4 in the example):

  int main (void)
  {
      extern int func_4 (void);
  
      /* Call function at byte address 0x4 */
      return func_4();
  }
  

  and the application be linked with -Wl,--defsym,func_4=0x4. Alternatively, func_4 can be defined in the linker script.

3.19.6.2 Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers ¶

Some AVR devices support memories larger than the 64 KiB range that can be accessed with 16-bit pointers. To access memory locations outside this 64 KiB range, the content of a RAMP register is used as high part of the address: The X, Y, Z address register is concatenated with the RAMPX, RAMPY, RAMPZ special function register, respectively, to get a wide address. Similarly, RAMPD is used together with direct addressing.

• The startup code initializes the RAMP special function registers with zero.
• If a named address space other than generic or __flash is used, then RAMPZ is set as needed before the operation.
• If the device supports RAM larger than 64 KiB and the compiler needs to change RAMPZ to accomplish an operation, RAMPZ is reset to zero after the operation.
• If the device comes with a specific RAMP register, the ISR prologue/epilogue saves/restores that SFR and initializes it with zero in case the ISR code might (implicitly) use it.
• RAM larger than 64 KiB is not supported by GCC for AVR targets. If you use inline assembler to read from locations outside the 16-bit address range and change one of the RAMP registers, you must reset it to zero after the access.

3.19.6.3 AVR Built-in Macros ¶

GCC defines several built-in macros so that the user code can test for the presence or absence of features. Almost any of the following built-in macros are deduced from device capabilities and thus triggered by the -mmcu= command-line option.

For even more AVR-specific built-in macros see AVR Named Address Spaces and AVR Built-in Functions.

__AVR_ARCH__

Build-in macro that resolves to a decimal number that identifies the architecture and depends on the -mmcu=mcu option. Possible values are:

2, 25, 3, 31, 35, 4, 5, 51, 6

for mcu=avr2, avr25, avr3, avr31, avr35, avr4, avr5, avr51, avr6,

respectively and

100, 102, 103, 104, 105, 106, 107

for mcu=avrtiny, avrxmega2, avrxmega3, avrxmega4, avrxmega5, avrxmega6, avrxmega7, respectively. If mcu specifies a device, this built-in macro is set accordingly. For example, with -mmcu=atmega8 the macro is defined to 4.

__AVR_Device__

Setting -mmcu=device defines this built-in macro which reflects the device’s name. For example, -mmcu=atmega8 defines the built-in macro __AVR_ATmega8__, -mmcu=attiny261a defines __AVR_ATtiny261A__, etc.

The built-in macros’ names follow the scheme __AVR_Device__ where Device is the device name as from the AVR user manual. The difference between Device in the built-in macro and device in -mmcu=device is that the latter is always lowercase.

If device is not a device but only a core architecture like ‘avr51’, this macro is not defined.

__AVR_DEVICE_NAME__

Setting -mmcu=device defines this built-in macro to the device’s name. For example, with -mmcu=atmega8 the macro is defined to atmega8.

If device is not a device but only a core architecture like ‘avr51’, this macro is not defined.

__AVR_XMEGA__

The device / architecture belongs to the XMEGA family of devices.

__AVR_HAVE_ADIW__

The device has the ADIW and SBIW instructions.

__AVR_HAVE_ELPM__

The device has the ELPM instruction.

__AVR_HAVE_ELPMX__

The device has the ELPM Rn,Z and ELPM Rn,Z+ instructions.

__AVR_HAVE_LPMX__

The device has the LPM Rn,Z and LPM Rn,Z+ instructions.

__AVR_HAVE_MOVW__

The device has the MOVW instruction to perform 16-bit register-register moves.

__AVR_HAVE_MUL__

The device has a hardware multiplier.

__AVR_HAVE_JMP_CALL__

The device has the JMP and CALL instructions. This is the case for devices with more than 8 KiB of program memory.

__AVR_HAVE_EIJMP_EICALL__

__AVR_3_BYTE_PC__

The device has the EIJMP and EICALL instructions. This is the case for devices with more than 128 KiB of program memory. This also means that the program counter (PC) is 3 bytes wide.

__AVR_2_BYTE_PC__

The program counter (PC) is 2 bytes wide. This is the case for devices with up to 128 KiB of program memory.

__AVR_HAVE_8BIT_SP__

__AVR_HAVE_16BIT_SP__

The stack pointer (SP) register is treated as 8-bit respectively 16-bit register by the compiler. The definition of these macros is affected by -mtiny-stack.

__AVR_HAVE_SPH__

__AVR_SP8__

The device has the SPH (high part of stack pointer) special function register or has an 8-bit stack pointer, respectively. The definition of these macros is affected by -mmcu= and in the cases of -mmcu=avr2 and -mmcu=avr25 also by -msp8.

__AVR_HAVE_RAMPD__

__AVR_HAVE_RAMPX__

__AVR_HAVE_RAMPY__

__AVR_HAVE_RAMPZ__

The device has the RAMPD, RAMPX, RAMPY, RAMPZ special function register, respectively.

__NO_INTERRUPTS__

This macro reflects the -mno-interrupts command-line option.

__AVR_ERRATA_SKIP__

__AVR_ERRATA_SKIP_JMP_CALL__

Some AVR devices (AT90S8515, ATmega103) must not skip 32-bit instructions because of a hardware erratum. Skip instructions are SBRS, SBRC, SBIS, SBIC and CPSE. The second macro is only defined if __AVR_HAVE_JMP_CALL__ is also set.

__AVR_ISA_RMW__

The device has Read-Modify-Write instructions (XCH, LAC, LAS and LAT).

__AVR_SFR_OFFSET__=offset

Instructions that can address I/O special function registers directly like IN, OUT, SBI, etc. may use a different address as if addressed by an instruction to access RAM like LD or STS. This offset depends on the device architecture and has to be subtracted from the RAM address in order to get the respective I/O address.

__AVR_SHORT_CALLS__

The -mshort-calls command line option is set.

__AVR_PM_BASE_ADDRESS__=addr

Some devices support reading from flash memory by means of LD* instructions. The flash memory is seen in the data address space at an offset of __AVR_PM_BASE_ADDRESS__. If this macro is not defined, this feature is not available. If defined, the address space is linear and there is no need to put .rodata into RAM. This is handled by the default linker description file, and is currently available for avrtiny and avrxmega3. Even more convenient, there is no need to use address spaces like __flash or features like attribute progmem and pgm_read_*.

__AVR_HAVE_FLMAP__

This macro is defined provided the following conditions are met:

• The device has the NVMCTRL_CTRLB.FLMAP bitfield. This applies to the AVR64* and AVR128* devices.
• It’s not known at assembler-time which emulation will be used.

This implies the compiler was configured with GNU Binutils that implement PR31124.

__AVR_RODATA_IN_RAM__

This macro is undefined when the code is compiled for a core architecture.

When the code is compiled for a device, the macro is defined to 1 when the .rodata sections for read-only data is located in RAM; and defined to 0, otherwise.

__WITH_AVRLIBC__

The compiler is configured to be used together with AVR-Libc. See the --with-avrlibc configure option.

__HAVE_DOUBLE_MULTILIB__

Defined if -mdouble= acts as a multilib option.

__HAVE_DOUBLE32__

__HAVE_DOUBLE64__

Defined if the compiler supports 32-bit double resp. 64-bit double. The actual layout is specified by option -mdouble=.

__DEFAULT_DOUBLE__

The size in bits of double if -mdouble= is not set. To test the layout of double in a program, use the built-in macro __SIZEOF_DOUBLE__.

__HAVE_LONG_DOUBLE32__

__HAVE_LONG_DOUBLE64__

__HAVE_LONG_DOUBLE_MULTILIB__

__DEFAULT_LONG_DOUBLE__

Same as above, but for long double instead of double.

__WITH_DOUBLE_COMPARISON__

Reflects the --with-double-comparison={tristate|bool|libf7} configure option and is defined to 2 or 3.

__WITH_LIBF7_LIBGCC__

__WITH_LIBF7_MATH__

__WITH_LIBF7_MATH_SYMBOLS__

Reflects the --with-libf7={libgcc|math|math-symbols} configure option.

3.19.6.4 AVR Internal Options ¶

The following options are used internally by the compiler and to communicate between device specs files and the compiler proper. You don’t need to set these options by hand, in particular they are not optimization options. Using these options in the wrong way may lead to sub-optimal or wrong code. They are documented for completeness, and in order to get a better understanding of device specs files.

-mn-flash=num ¶

Assume that the flash memory has a size of num times 64 KiB. This determines which __flashN address spaces are available.

-mflmap ¶

The device has the FLMAP bit field located in special function register NVMCTRL_CTRLB.

-mrmw ¶

Assume that the device supports the Read-Modify-Write instructions XCH, LAC, LAS and LAT.

-mshort-calls ¶

Assume that RJMP and RCALL can target the whole program memory. This option is used for multilib generation and selection for the devices from architecture avrxmega3.

-mskip-bug ¶

Generate code without skips (CPSE, SBRS, SBRC, SBIS, SBIC) over 32-bit instructions.

-msp8 ¶

Treat the stack pointer register as an 8-bit register, i.e. assume the high byte of the stack pointer is zero. This option is used by the compiler to select and build multilibs for architectures avr2 and avr25. These architectures mix devices with and without SPH.