[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] -mmcu=avrxmega confusion
From: |
Georg-Johann Lay |
Subject: |
[avr-gcc-list] -mmcu=avrxmega confusion |
Date: |
Mon, 20 Feb 2012 14:09:41 +0100 |
User-agent: |
Thunderbird 2.0.0.24 (X11/20100302) |
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] -mmcu=avrxmega confusion,
Georg-Johann Lay <=