Strona g?ówna Artyku?y ARM bleeding-edge-toolchain - o co chodzi?
bleeding-edge-toolchain - o co chodzi?
Ocena użytkownikĆ³w: / 35
SłabyŚwietny 
Wpisany przez Freddie Chopin   
Sobota, 09 Luty 2013 14:55

Niektórzy zapewne zauwa?yli, ?e w dziale Download pojawi?a si? nowa kategoria - Programy > bleeding-edge-toolchain - a w niej ca?kiem spore pliki o nazwach wskazuj?cych na to, i? s? to kompilatory typu bare-metal dla uk?adów z rdzeniem ARM... "Na rynku" jest ju? przecie? CodeSourcery (zwane teraz Sourcery CodeBench), linaro, Yagarto, jakby si? uprze? s? jeszcze prehistoryczne pakiety GNUARM i WinARM, zapewne jeszcze kilka o których (na razie) nie wiem - po co wi?c kolejny? Nawet nazwy sensownej mu nada? nie mo?na, bo Yet Another Gnu ARm TOolchain jest ju? zaj?te (;

Mo?e wi?c na pocz?tek odrobin? historii. W zamierzch?ych czasach (czyli jakie? 3-4 lata temu [; ), gdy ARMy zaczyna?y si? robi? naprawd? popularne (Cortex-M3 i te sprawy), najlepszym wyborem by? pakiet CodeSourcery - by?a dost?pna wersja dla Windowsa i Linuxa, pakiet by? regularnie uaktualniany, programi?ci z firmy tworz?cej go wspó?pracowali pono? z firm? ARM, no generalnie wszystko co trzeba. Niezliczone ilo?ci stron w internecie (z t? w??cznie) polecaj? go jako dobry punkt startu.

Gdy wysz?y jednak pierwsze uk?ady z rdzeniem Cortex-M4 i zintegrowan? jednostk? zmiennoprzecinkow? pojawi? si? pierwszy zgrzyt... Wpisuj?c w konsoli arm-none-eabi-gcc -print-multi-lib otrzymujemy mniej wi?cej co? takiego:

...\Sourcery_CodeBench_Lite_for_ARM_EABI\bin>arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
armv6-m;@mthumb@march=armv6-m
thumb2;@mthumb@march=armv7@mfix-cortex-m3-ldrd

...\Sourcery_CodeBench_Lite_for_ARM_EABI\bin>arm-none-eabi-gcc --version
arm-none-eabi-gcc (Sourcery CodeBench Lite 2012.09-63) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Oznacza to w skrócie tyle, ?e toolchain ten ma zintegrowane biblioteki standardowe (czyli np. bibliotek? libm.a z funkcjami matematycznymi) dla "standardowej" architektury ARM7 (ARMv4, tryb ARM i tryb THUMB) oraz dla Cortex-M0 (ARMv6-M, THUMB) oraz Cortex-M3 (ARMv7-M, THUMB2). Oczywi?cie przy pomocy tego toolchaina mo?na tworzy? kod dla Cortex-M4, poniewa? architektura ARMv7-ME jest tylko "rozwini?ciem" architektury ARMv7-M, ale o u?yciu FPU (Floating Point Unit) musimy cz?sto zapomnie?. Je?li kto? ma fantazj? to zawsze mo?na oczywi?cie pisa? w assemblerze lub korzysta? z funkcji wchodz?cych w sk?ad CMSIS, jednak podstawowe rzeczy, np.:

float a = 1.0f;
float b = logf(a);

zamiast skorzysta? z dobrodziejstw FPU wykonaj? si? przy u?yciu algorytmów w 100% programowych... Dodatkowo w 2010 roku CodeSourcery zostaje przej?te przez firm? Mentor Graphics i support dla darmowej edycji Lite praktycznie zanika. Sugestie o dodanie wsparcia dla FPU w architekturze ARMv7-ME zbywane s? informacj?, ?e takie opcje (i nie tylko) dost?pne s? w p?atnej wersji...

Na szcz??cie w tym samym czasie (2010) powstaje organizacja linaro, sk?adaj?ca si? z firmy ARM i kilku jej najwi?kszych partnerów, której celem jest rozwój i wspieranie otwartych narz?dzi dla najnowszych uk?adów z rdzeniem ARM. Cho? nie da si? ukry?, ?e g?ównym "targetem" dla linaro s? procesory aplikacyjne z rdzeniem ARM Cortex-A i systemy typu Linux czy Android, to pod koniec 2011 roku pojawia si? pierwsze wydanie pakietu o nazwie GNU Tools for ARM Embedded Processors. Od tego czasu nowe wersje pojawiaj? si? 3-4x w roku i zawieraj? najnowsz? wersj? kompilatora, pochodz?c? z brancha przeznaczonego specjalnie dla mikrokontrolerów (w tamtym czasie - /branches/ARM/embedded-4_6-branch, obecnie - /branches/ARM/embedded-4_7-branch). Dla odmiany wzgl?dem pakietu CodeSourcery, pakiet ten zawiera bardzo bogat? kolekcj? bibliotek:

...\GNU Tools ARM Embedded\4.7 2012q4\bin>arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
armv6-m;@mthumb@march=armv6s-m
armv7-m;@mthumb@march=armv7-m
armv7e-m;@mthumb@march=armv7e-m
armv7-r/thumb;@mthumb@march=armv7-r
armv7e-m/softfp;@mthumb@march=armv7e-m@mfloat-abi=softfp@mfpu=fpv4-sp-d16
armv7e-m/fpu;@mthumb@march=armv7e-m@mfloat-abi=hard@mfpu=fpv4-sp-d16
armv7-r/thumb/softfp;@mthumb@march=armv7-r@mfloat-abi=softfp@mfpu=vfpv3-d16
armv7-r/thumb/fpu;@mthumb@march=armv7-r@mfloat-abi=hard@mfpu=vfpv3-d16

...\GNU Tools ARM Embedded\4.7 2012q4\bin>arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.7.3 20121207
(release) [ARM/embedded-4_7-branch revision 194305]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Jak wida? pakiet ten wspiera "klasyczne" ARM7 (ARM, THUMB), Cortex-M (ARMv6-M, ARMv7-M, ARMv7-ME) oraz Cortex-R (ARMv7-R) - wszystkie z mo?liwo?ci? wykorzystania sprz?towego FPU.

W tym momencie niektórzy mog? zapewne przesta? czyta? pytaj?c na g?os "czego chcie? wi?cej?"... Z pakietami linaro by?oby wszystko w porz?dku, gdyby nie jeden drobny problem - z niewiadomych przyczyn kompilacja dowolnego projektu trwa w nim 3-4x d?u?ej ni? w pakiecie CodeSourcery...

Jednocze?nie - bez zwi?zku z powy?szym - od czasu do czasu mia?em potrzeb? stworzy? jaki? kod w C++ i we znaki dawa?y mi si? wyj?tki, których wbrew zasadzie "you don't pay for what you don't use" wcale nie da si? po prostu wy??czy?. Aby si? ich pozby? (oczywi?cie ze wzgl?dów na rozmiar pami?ci w mikrokontrolerze) konieczna jest rekompilacja biblioteki standardowej C i C++ wchodz?cej w sk?ad kompilatora. (efekty tych kilku kompilacji mo?na zreszt? pobra? z dzia?u Download > ARM > Ró?ne - s? tam dost?pne paczki z samymi bibliotekami kompilatora z wy??czonymi wyj?tkami C++)

Ostatnio za?, przy okazji projektu jakim si? zajmowa?em, mia?em te? potrzeb? skorzystania z nowej wersji biblioteki newlib, poniewa? (z moj? pomoc?) znajdowa?a si? tam poprawka drastycznie ograniczaj?ca zu?ycie pami?ci przez funkcj? fprintf(). Z racji tego, ?e projekt ten by? dosy? spory, d?ugi czas kompilacji zacz?? mnie naprawd? irytowa? wi?c postanowi?em sprawdzi?, czy wykorzystanie 64-bitowego procesora pozwoli znacz?co przyspieszy? proces kompilacji.

Ostatni eksperyment pokaza?, ?e u?ycie 64-bitowego kompilatora niewiele zmienia wzgl?dem wersji 32-bitowej (zysk poni?ej 10%), ale i tak "wyprodukowane" przezemnie kompilatory s? kilkukrotnie szybsze ni? oryginalne linaro, osi?gaj?c "wydajno??" równ? pakietom CodeSourcery. No i tak w?a?nie narodzi?a si? koncepcja bleeding-edge-toolchain.

Podstawowe za?o?enia s? wi?c nast?puj?ce:

  • oparty o pakiety linaro,
  • skompilowany najnowszym dost?pnym kompilatorem, dla Windowsa u?yty zostaje nowoczesny kompilator mingw-w64,
  • podstawowe komponenty (kompilator, newlib, gdb i binutils) pochodz? wprost z repozytoriów projektów, wykorzystane s? najnowsze rewizje,
  • pozosta?e komponenty (biblioteki potrzebne do kompilacji toolchaina) s? w najnowszych stabilnych wersjach (chyba ?e dokumentacja zaleca zastosowanie konkretnej wersji),
  • wy??czona obs?uga wyj?tków C++ (pracuj? nad dost?pno?ci? obydwóch wersji bibliotek, wybieranych przez pliki .specs),
  • wszystkie biblioteki kompilatora maj? pozostawione informacje konieczne do debuggowania ich (nie s? "stripped"),
  • biblioteka newlib z w??czon? opcj? reent-small i z wy??czonym wsparciem dla 64-bitowych liczb w funkcjach typu printf()/sprintf().

Jaki jest zysk z u?ycia takiego toolchaina? Przeprowadzi?em wyj?tkowo nudne porównanie czasu kompilacji dla 6 ró?nych projektów, porównuj?c 3 pakiety w najnowszych wersjach (bleeding-edge-toolchain-130207 [32-bit], linaro - GCC ARM Embedded 4.7-2012-q4-major, CodeSourcery - Sourcery CodeBench Lite 2012.09-63) zarówno przy kompilacji sekwencyjnej jak i wielow?tkowej (2 w?tki). Wyniki przedstawia poni?sza tabela.

 

rozmiar pliku wynikowego ilo?? plików ?ród?owych BET -j1 BET -j2 linaro -j1 linaro -j2 cs -j1 cs -j2
p1 12kB 29 12s 8s 48s 27,5s 12s 8s
p2 17kB 23 19s 12s 51,5s 30,5s 19,5s 12s
p3 30kB 39 17s 11,5s 62s 36,5s 16s 11s
p4 60kB 567 85,5s 40,5s* 96,5s 42s* 91s 40s*
p5 100kB 71 38,5s 24s 104,5s 59,5s -** -**
p6 130kB (30kB)*** 60 26,5s 18s 92s 54,5s 27s 17s

 

* - kompilacja przeprowadzona przy u?yciu systemu tup, oryginalne pliki Makefile tego projektu nie nadaj? si? do kompilacji wielow?tkowej
** - brak mo?liwo?ci kompilacji ze wzgl?du na niekompatybilno?? projektu i bibliotek kompilatora (inne opcje dotycz?ce reentrancy)
*** - oko?o 100kB to rozmiar bitmap i czcionek, projekt zawiera oko?o 30kB kodu

Wyniki s? ?redni? z dwóch kompilacji. Ka?da kompilacja by?a poprzedzona pe?nym "wyczyszczeniem" projektu (make clean). Liczba plików ?ród?owych uwzgl?dnia tylko pliki które faktycznie by?y kompilowane (jest to w zasadzie liczba powsta?ych plików obiektowych). Pomiarów dokonano przy u?yciu skryptu.

W ramach nagrody za te testy pozwol? sobie na drobny komentarz w punktach.

  1. Pakiet CodeSourcery zawiera w teorii inn? wersj? kompilatora (4.7.2) ni? dwa pozosta?e (4.7.3 prerelease).
  2. Projekt p4 ze wzgl?du na 567 plików ?ród?owych w zasadzie nie nadaje si? do tego porównania - przypuszczalnie wi?kszo?? czasu komputer marnuje na uruchamianie kolejnych procesów kompilatora, wi?c wyniki dla wszystkich 3 pakietów s? porównywalne.
  3. Wykluczaj?c wspomniany powy?ej projekt p4 mo?na powiedzie?, ?e czas kompilacji przy u?yciu bleeding-edge-toolchain jest 2.5-4x krótszy ni? przy u?yciu pakietu linaro.
  4. Wyniki bleeding-edge-toolchain s? praktycznie identyczne do wyników CodeSourcery.
  5. Bli?sze przyjrzenie si? informacjom ze strony pakietu linaro ka?e przypuszcza?, ?e powodem d?ugiej kompilacji mo?e by? u?ycie wyj?tkowo starej wersji systemu (Ubuntu-8.10) i narz?dzi do kompilacji tego? pakietu - zapewne w celu wi?kszej kompatybilno?ci ze starszymi systemami operacyjnymi.

Ze wzgl?dów na to, ?e kompilacj? pakietu przeprowadza?em przy u?yciu 64-bitowego Linuxa nie uda?o mi si? niestety skompilowa? pakietu w wersji na 32-bitowy system Linux, jednak zawarte w ka?dej paczce skrypty przeprowadzaj?ce kompilacj? pozwol? ka?demu u?ytkownikowi takiego systemu na przeprowadzenie kompilacji we w?asnym zakresie (; Mo?e w przysz?o?ci uda mi si? skompilowa? te? i tak? wersj? - kto wie, na pewno b?d? próbowa? (;

Je?li wi?c kogo? równie mocno jak mnie denerwuj? d?ugie czasy kompilacji, to zapraszam do pobierania i u?ywania pakietu bleeding-edge-toolchain (; Komentarze oczywi?cie jak zwykle mile widziane (;

Zmieniony: Niedziela, 10 Luty 2013 14:38