At current, avr-tools' xmega core <-> device mapping looks as follows:
binutils: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-avr.c?rev=1.79&content-type=text/x-cvsweb-markup&cvsroot=src gcc: http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-mcus.def?revision=184269&view=markup http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-devices.c?revision=184269&view=markup Or, in prose: avrxmega2: ELPM=0, EIND=0, RAMPD=0 atxmega16a4 atxmega16d4 atxmega16x1 atxmega32a4 atxmega32d4 atxmega32x1 avrxmega4: ELPM=0, EIND=0, RAMPD=0 atxmega64a3 atxmega64d3 avrxmega5: ELPM=0, EIND=0, RAMPD=1 atxmega64a1 atxmega64a1u avrxmega6: ELPM=1, EIND=1, RAMPD=0 atxmega128a3 atxmega128b1 atxmega128d3 atxmega192a3 atxmega192d3 atxmega256a3 atxmega256a3b atxmega256a3bu atxmega256d3 avrxmega7: ELPM=1, EIND=0, RAMPD=1 atxmega128a1 atxmega128a1u Could someone explain this to me? For the compiler's perspective, devices are filed under core architectures that differ in instruction set architecture (ISA) or special function register (SFR) layout like address of SREG. xmega all have the same SFR addresses -- at least as far as only addresses are concerned which the compiler is using, for example SP or RAMPZ. The ISA decomposes on the basis of availability of the following instructions and SFRs: EIJMP/EIND, ELPM, JMP, RAMPD Other instructions like MUL, MOVW don't matter here because all xmega ISA support them. JMP, ELPM, EIJMP depend only on the flash size and there are the implications EIJMP => ELPM => JMP so that in the (EIJMP, ELPM, JMP, RAMPD) quadruple only the following elements are of interest: (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 0) (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 1) (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 0) (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 1) (EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 0) (EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 1) (EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 0) (EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 1) Currently there are no devices with <= 8 KiB if flash so that the 2 combinations 0000 and 0001 are not needed. However, the current mapping from above is 0010: avrxmega2: ELPM=0, RAMPD=0, EIND=0 atxmega16a4 atxmega16d4 atxmega16x1 atxmega32a4 atxmega32d4 atxmega32x1 0010: avrxmega4: ELPM=0, EIND=0, RAMPD=0 atxmega64a3 atxmega64d3 0011: avrxmega5: ELPM=0, EIND=0, RAMPD=1 atxmega64a1 atxmega64a1u 1110 and 0110: avrxmega6: ELPM=1, EIND=0/1, RAMPD=0 atxmega128a3 atxmega128b1 atxmega128d3 atxmega192a3 atxmega192d3 atxmega256a3 atxmega256a3b atxmega256a3bu atxmega256d3 0111: avrxmega7: ELPM=1, EIND=0, RAMPD=1 atxmega128a1 atxmega128a1u Enumerating the quadruples starting at 0 we have: avrxmega0 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 0) avrxmega1 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 0, 1) avrxmega2 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 0) avrxmega3 = (EIJMP, ELPM, JMP, RAMPD) = (0, 0, 1, 1) avrxmega4 = (EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 0) avrxmega5 = (EIJMP, ELPM, JMP, RAMPD) = (0, 1, 1, 1) avrxmega6 = (EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 0) avrxmega7 = (EIJMP, ELPM, JMP, RAMPD) = (1, 1, 1, 1) And thus the following mapping: 0010: avrxmega2: ELPM=0, EIND=0, RAMPD=0 atxmega16a4 atxmega16d4 atxmega16x1 atxmega32a4 atxmega32d4 atxmega32x1 atxmega64a3 atxmega64d3 0011: avrxmega3: ELPM=0, EIND=0, RAMPD=1 atxmega64a1 atxmega64a1u 0110: avrxmega4: ELPM=1, EIND=0, RAMPD=0 atxmega128a3 atxmega128b1 atxmega128d3 0111: avrxmega5: ELPM=1, EIND=0, RAMPD=1 atxmega128a1 atxmega128a1u 1110: avrxmega6: ELPM=1, EIND=1, RAMPD=0 atxmega192a3 atxmega192d3 atxmega256a3 atxmega256a3b atxmega256a3bu atxmega256d3 avrxmega0/1/7: empty The current device core assignment allows code like void foo0 (void) {} void (*pfoo)(void) = foo0; int main() { pfoo(); return 0; } to be compiled avr-gcc eijmp.c -o eijmp.elf -mmcu=atxmega128a3 -save-temps -dp -Os and the compiler emit EICALL and the elf disassembly reads 00000220 <main>: 220: e0 91 00 20 lds r30, 0x2000 224: f0 91 01 20 lds r31, 0x2001 228: 19 95 eicall 22a: 80 e0 ldi r24, 0x00 ; 0 22c: 90 e0 ldi r25, 0x00 ; 0 22e: 08 95 ret which is not what I'd expect for a device with <= 64 Ki words flash. Obviously there is some device/core/ISA/avrxmega(n) confusion throughout the tools that must be resolved. Thoughts? Johann _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
