- A GCC 16 natív támogatást nyújt a Picolibc-hez, egy ultra-pehelysúlyú libc C-hez, amely beágyazott rendszerekhez készült.
- Az integráció célokat ad hozzá
*-picolibc-*és új lehetőségek, mint például--oslib=,--crt0=y--printf=. - A Picolibc jelentősen csökkenti a firmware méretét a Newlibhez és a Newlib-nano-hoz képest, ami kulcsfontosságú az IoT és az edge alkalmazások számára.
- A GCC 16 ezt a támogatást a modern architektúrák fejlesztéseivel és alapértelmezés szerint a C++20-szal ötvözi, megerősítve szerepét a beágyazott ökoszisztémában.
A GCC 16 érkezése a Picolibc natív támogatásával jelentős izgalmat kelt a beágyazott fejlesztői közösségben . Ez nem csupán a régi fordítóprogram "újabb verziója", hanem jelentős lépés a sokkal könnyebb és finomított eszközláncok felé mikrokontrollerekhez, IoT-eszközökhöz és peremhálózati rendszerekhez, ahol minden bájt számít.
A lépés mögött a veterán fejlesztő, Keith Packard áll, aki jól ismert az X.Org-on végzett munkájáról , és évek óta a Picolibc-et minimalista C szabványkönyvtárként népszerűsíti beágyazott rendszerekhez. A GCC 16-ba való integrációjával végre megszűnt az egyéni javítások, a szokatlan konfigurációk és a könyvtár összekapcsolásához szükséges hackek iránti igény: a Picolibc a GCC ökoszisztéma teljes értékű tagjává válik.
Mi a Picolibc, és miért van integrálva a GCC 16-ba?
A Picolibc egy ultra-pehelysúlyú C szabványkönyvtár, amelyet kifejezetten 32 és 64 bites beágyazott rendszerekhez terveztek. A Newlib és az AVR Libc konvergenciájából és refaktorálásából született, egyértelmű céllal: a ROM és RAM használatának minimalizálása az alapvető C nyelvi funkciók feláldozása nélkül.
Más, nehezebb alternatívákkal ellentétben a Picolibc-t úgy tervezték, hogy a linker könnyen eldobhatja a fel nem használt kódot , nagyon finoman szabályozva afelett, hogy a könyvtár mely részei kerüljenek a végső bináris fájlba. Ez ideális olyan mikrokontrollerek számára, ahol a tárhely néhány kilobájtban mérhető, és minden további kódszakasz költségeket, erőforrás-felhasználást és bonyolultságot okoz.
Eddig a Picolibc és a GCC együttes használata azt jelentette , hogy szinte teljes egészében kézzel kellett felépíteni egy eszközláncot : a könyvtár fordítását, a sysroot finomhangolását, az indító szkriptek módosítását, a javítások alkalmazását és így tovább. Az eredmény lenyűgöző volt, de a súrlódások sok csapatot elriasztottak. A GCC 16-tal ez a helyzet gyökeresen megváltozik, mivel a fordító közvetlen és hivatalos támogatást nyújt ehhez a beágyazott libc-hez.
A lényeg az, hogy a GCC 16 kódfája tartalmazza a felismeréshez szükséges változtatásokat típusú célpontok *-picolibc-* és a konfigurációs opció --with-picolibcÍgy a fordítóprogram építésekor vagy egy előre elkészített eszközlánc használatakor, A Picolibc gyárilag támogatott opcióvá válik, mindenféle barkácsolás nélkül.
Picolibc integráció a GCC 16-ban: részletek és új lehetőségek
A GCC 16 repositoryba integrált patch nemcsak a Picolibc-t ismeri fel alternatív libc-ként, hanem speciális fordítási lehetőségeket is bevezet, amelyek célja, hogy kihasználják ezt a könnyűsúlyú környezetet a beágyazott rendszerekben.
Egyrészt a GCC most már zökkenőmentesen tud együttműködni a következőkkel: a stílus céljai *-picolibc-* (például arm-none-picolibc-eabiTovábbá a GCC fordításakor átadható --with-picolibc hogy a konfigurátor előkészítse a környezetet ezzel a könyvtárral, mint fő céllal, kezelve sysroot, fejlécek és rendszerindító fájlok akkordok a Picolibc-hez.
Ezen alapvető integráció mellett a patch számos nagyon érdekes további lehetőséget kínál a Picolibc-re fordítva:
--oslib=Lehetővé teszi különböző modulok kiválasztását, amelyek megvalósítják az operációs rendszerrel vagy a futási környezettel való interfészt, ami kulcsfontosságú, ha csupasz fémen dolgozol. Könnyű RTOS vagy szimulátorokban.--crt0=: a C rendszerindító fájlt adja meg (crt0) használható, ami helyet biztosít módosítsa a rendszerindítási sorrendet minden egyes alaplaphoz, rendszerbetöltőhöz vagy inicializálási követelményekhez.--printf=teljes körű megvalósítása között kínál választási lehetőséget.printfvagy rövidített változatok, például egész számokra összpontosító minimalista verziók amelyek jelentős mennyiségű programmemóriát takarítanak meg.
Ez az utolsó lehetőség gyakran nagy különbséget jelent a valós projektekben: a függvények családja printf Ez általában a legnehezebb rész libc-ből. A csökkentett verzió választásának lehetősége, amely esetleg csak az alapvető UART naplókhoz szükséges fájlokat tartalmazza, lehetővé teszi a végső bináris fájl sokkal kompaktabb elkészítését, ami létfontosságú a nagyon alacsony költségű eszközökben.
Néhány folyamat makrókat és jelzőket is használ, például -Dsystem-libc és a Picolibc-hez társított sysroot konfigurációkat, így a fordító ezt a könyvtárat tekinti a a libc alapértelmezett implementációja anélkül, hogy minden GCC-híváshoz tucatnyi jelzőt kellene hozzáadni.
Az út a „libc diverzitás” felé a GCC-ben
A Picolibc felvétele a GCC 16-ba nem a semmiből jött; megelőzte azt egy vita a GCC projekten belül arról, hogy elő kell-e mozdítani a hivatalosan támogatott C könyvtárak sokféleségét . Körülbelül egy évvel ezelőtt már szóba kerültek a levelezőlistákon a különböző, adott kontextusokhoz igazított könyvtárak engedélyezése, és a Picolibc egyértelmű jelöltként jelent meg a beágyazott világ számára.
Ez idő alatt Keith Packard elment a javítás egymást követő verzióinak polírozása és beküldése a listára gcc-patchesAz integrációt a fordító minőségi és karbantarthatósági szabványainak megfelelően módosították. A GCC karbantartóival folytatott megbeszélések során finomították a részleteket, például a célpontok kiválasztását, a támogatott fájlok szervezését és az egyéni beállítások használatát.
Ennek az együttműködésnek az eredménye egy olyan integráció, amely nem pusztán egy kiegészítő, hanem inkább a GCC belső architektúrájához jól illeszkedő kiterjesztés . Ez megerősíti a „libc diverzitás” gondolatát: mostantól a glibc, Newlib vagy uClibc-vel való szokásos kombinációk mellett bizonyos környezetekben a Picolibc is hozzáadásra került könnyűsúlyú és karbantartott alternatívaként magán a GCC fán belül.
Ez a megközelítés jól illeszkedik a jelenlegi iparági trendekhez, ahol az olyan architektúrák, mint a RISC-V, az új ARMv9 profilok és az alkalmazásspecifikus SoC-k terjednek. Egy moduláris és minimalista libc megkönnyíti, hogy ugyanaz a fordítóprogram alkalmazkodjon mind egy nagy teljesítményű szerverhez, mind egy érzékelőcsomóponthoz, mindössze néhány kilobájt flash memóriával.
Kapcsolat a Newlib, Newlib-nano és más könnyűsúlyú libcs-ekkel
Ahhoz, hogy megértsük, mit kínál a Picolibc, hasznos kontextusában összehasonlítani más klasszikus lehetőségekkel. A Newlib évek óta a libc szabványa a GCC-alapú beágyazott környezetekben, és olyan variánsok, mint a Newlib-nano, belőle származtak, amelyek célja a méret csökkentése bizonyos funkciók rovására.
A Picolibc ugyanezeket az eredeteket követi, de egy agresszívabb, a modularitásra összpontosító újratervezést alkalmaz . Az ötlet nem csak az, hogy a Newlib-et „egy kicsit kisebbé” tegyék, hanem az is, hogy átszervezzék, hogy a modern linkerek sokkal pontosabban tudják eltávolítani a fel nem használt kódot, maximalizálva a beépített funkciók és az elfoglalt hely arányát.
Közösségi elemzések (például beágyazott fejlesztői blogokon közzétett összehasonlítások) szerint a Picolibc-re való átállás jelentős csökkenést eredményezhet a flash használat, a bináris méret, a veremméret és a heap méret tekintetében a Newlib-hez és annak nano változatához képest. A gyakorlatban ez azt jelenti, hogy több alkalmazáslogika illeszthető ugyanarra a mikrovezérlőre, vagy kevesebb memóriával rendelkező mikrovezérlőre lehet lecserélni, ezáltal csökkentve a hardverköltségeket.
Ugyanakkor a Picolibc projekt nem ragad le az alapoknál: a tárolója bemutatja, hogyan támogatja a 16 bites célpontokat, javítja a POSIX kompatibilitást , és milyen finomításokat eszközölt, amelyek vonzóvá teszik még a kevésbé egzotikus architektúrák számára is: ARM Cortex-M, RISC-V, beágyazott MIPS és még sok más.
Más könnyűsúlyú alternatívákhoz, mint például a dietlibc vagy a különféle nanolib-ek, képest a Picolibc egyensúlyt teremt a méret és a szabványoknak való megfelelés között , ami különösen jól illeszkedik azokhoz a projektekhez, ahol konzisztens API-kra, intenzív tesztelésre és ugyanakkor nagyon kis helyigényegre van szükség.
Hogyan hasznosítsuk a Picolibc-et egy beágyazott munkafolyamatban?
A GCC 16 integrációja nagyon kézzelfogható változásokat jelent a firmware-fejlesztők mindennapi munkájában. Hogy ezt világosan lássuk, képzeljünk el egy tipikus projektet a következőhöz: ARM Cortex-M keresztfordítással egy fejlesztői PC-ről. Hagyományosan az eszközláncok, mint például arm-none-eabi a Newlib vagy a mikroprocesszor gyártójának saját SDK-jain alapul.
A GCC 16 segítségével olyan eszközláncot hozhat létre vagy tölthet le, amely már tartalmazza a következőket: egy célpont arm-none-picolibc-eabiA fordító konfigurálásakor a következő opcióval: --with-picolibcA környezet most már készen áll a libc szabványos használatára, a fejléceivel, a sysroot-tal és a megfelelő rendszerindító fájlokkal együtt.
Innentől kezdve a fordítás az új előtag használatával történik, például arm-none-picolibc-eabi-gcca szokásos optimalizálási és hibakeresési jelzőkkel együtt. Ha még jobban szeretné finomhangolni a méretet, használhatja a következő opciót: --printf= a változat kiválasztásához printf könnyebb, mint ami a projekt igényeit kielégíti.
A Make, CMake vagy más build rendszereket használó környezetekben a változás általában a következőre korlátozódik: eszközlánc definíciójának módosítása: adja meg az új előtagot, esetleg módosítson néhány csatolási beállítást, és ellenőrizze, hogy az indító szkriptek (crt0) és a linker szkriptfájlok illeszkednek a Picolibc szervezetéhez. Sok esetben ez a módosítás sokkal kisebb, mint ami már egy gyártói SDK-ról egy „tiszta” GCC eszközláncra való átállással jár.
Ez a folyamat utat nyit a zárt környezetek elhagyása, a különböző mikrovezérlő-családok közötti hordozhatóság elérése, valamint egy 100%-ban nyílt és auditálható eszközlánc fenntartása felé , ami egyre inkább értékes olyan ágazatokban, mint az ipar, az orvostudomány vagy az autóipar.
Hatás az IoT-re, a peremhálózati számítástechnikára és a szabályozott ágazatokra
Ennek az integrációnak az időzítése nem véletlen: egybeesik az IoT-eszközök és a peremhálózati rendszerek hatalmas térnyerésével , amelyek nagyon korlátozott erőforrásokkal működnek, gyakran akkumulátorról működnek és tömegesen kerülnek telepítésre. Ilyen esetekben a programmemória megtakarítása egyszerűen lehetővé teszi az olcsóbb mikrovezérlők használatát , és jelentősen csökkenti az egységköltségeket.
A firmware méretének csökkentése olyan folyamatokat is leegyszerűsít, mint az éteren keresztüli (OTA) frissítések , ahol minden egyes kilobájttal kevesebb gyorsabb átvitelt, alacsonyabb energiafogyasztást és az instabil hálózatokon előforduló hibák valószínűségének csökkenését jelenti. A Picolibc, mivel a GCC 16-tal kombinálva sokkal kompaktabb bináris fájlokat tesz lehetővé, közvetlen hatással van az ilyen típusú műveletekre.
A szabályozott iparágakban (egészségügy, autóipar, vasút stb.) az előnyök szintén észrevehetők. Míg egy LIBC hivatalos tanúsítása speciális eszközöket és folyamatokat igényel, egy kis, moduláris és viszonylag könnyen auditálható könyvtár megkönnyíti a tanúsított eszközláncok vagy az alapos biztonsági felülvizsgálatnak alávetett eszközök biztosítását.
Ugyanakkor ez az elkötelezettség a Picolibc iránt összhangban van a nyílt szilícium eszközláncok trendjével , ahogyan azt a RISC-V ökoszisztémában is láthatjuk. Ezekben a környezetekben a cél nemcsak az ISA nyíltsága, hanem az is, hogy a fordító, a libc és az eszközlánc többi része átlátható és a közösség által karbantartott legyen.
A GCC 16, a modern architektúrák (ARMv9.6-A, RISC-V, az x86 új generációi, mint például az AMD Zen 6 vagy az új Intel processzorok) támogatása és a Picolibc, mint pehelykönnyű libc, kombinációja megerősíti a GNU fordítót, mint az intelligens eszközök új hullámának központi pillérét , a viselhető eszközöktől az ipari érzékelőkig, amelyek lokális elemzési képességekkel rendelkeznek.
GCC 16 állapot, egyéb új funkciók és a támogatás érettsége
A GCC 16-ot a fordítóprogram főverziójaként tervezik a tipikus kiadási ciklusban , hozzávetőleges megjelenési időablakkal március és április között, ha minden a karbantartók tervei szerint halad. Miután a végső fejlesztési fázisba (4. szakasz) való belépés megerősítést nyert, a hangsúly kizárólag a dokumentációra és a regressziós javításokra helyeződött át , új funkciókkal nem bővült, kivéve a nagyon indokolt eseteket.
A legfrissebb jelentés megemlítette, hogy számos P1 prioritású regresszió , a legkritikusabb hiba, továbbra is megoldatlan maradt. Amíg ezeknek a hibáknak a száma el nem éri a nullát vagy egy elfogadható szintet, a GCC 16.1 első kiadásra jelölt verziói nem kerülnek generálásra. Ez a fegyelem biztosítja, hogy a Picolibc támogatása kellően érett állapotban kerüljön kiadásra ahhoz, hogy valós projektekben elkezdhesse használni.
A Picolibc támogatása mellett a GCC 16 számos új funkciót is tartalmaz: a célnyelvi támogatást Armv9.6-A, az AMD Zen 6 architektúra kezdeti implementációja (azonosítva: Znver6) az új ISA-képességeivel, a kezelésében elért fejlesztésekkel menedzselt memória AMD GPU-kban, a következő generációs Intel processzorok, például a Nova Lake és a Wildcat Lake támogatása, valamint az LTO (Link Time Optimization) alapértelmezett partícióinak számának növelése, többek között.
A nyelv tekintetében az egyik legfeltűnőbb változás, hogy a C++20 lesz az alapértelmezett szabvány, ha nincs más megadva. Egy új front-end is hozzáadódott az Algol 68-hoz, kibővítve a GCC által támogatott nyelvek listáját. Mindezt hibajavítások és kisebb optimalizálások egészítik ki a különböző back-endeken.
Összességében a GCC 16 nem csak "az a verzió, amelyben a Picolibc benne van". Ez egy erős kiadás az architektúra támogatása, a C++ modernizációja és a jelenlegi hardverekhez való képességek tekintetében, ahol a pehelysúlyú libc beépítése egy szélesebb körű stratégia része, amely a modern fejlesztési igényekhez való alkalmazkodást célozza , mind az asztali gépeken, mind különösen a beágyazott rendszereken.
A műszaki közösségek és a szakosodott média összegyűjti ezeket az új fejleményeket: a Picolibc támogatására és a „libc diverzitás” gondolatára összpontosító cikkektől kezdve az olyan új architektúrák, mint az AMD Zen 6, következményeinek elemzésein át a közösségi hálózatokon folytatott megbeszélésekig arról, hogyan lehet kihasználni a GCC 16 előnyeit a retró konzoloktól az ipari vezérlésekig terjedő projektekben.
Minden arra utal, hogy ahogy közeledik a GCC 16.1 végleges kiadása és az integrált Picolibc-et tartalmazó első eszközláncok stabilizálódnak, egyre több valós használati esetet, összehasonlító méret- és teljesítménytesztet, valamint gyakorlati útmutatókat fogunk látni a bare metalról, a linker szkriptekről és az új kombinációt használó specifikus rendszerindítási szekvenciákról .
A GCC 16-ban a Picolibc támogatása fordulópontot jelent a beágyazott ökoszisztéma számára: drasztikusan csökkenti az ultralight libc bevezetésével járó súrlódást, megnyitja az utat a kisebb, karbantarthatóbb firmware előtt , és összhangban van a nyílt, konfigurálható, a különféle architektúrákhoz igazított eszközláncok felé mutató általános trenddel. Sok fejlesztőcsapat számára érdemes már most elkezdeni a GCC 16 ágak tesztelését a Picolibc-vel, mérni a méretre, a teljesítményre és a karbantarthatóságra gyakorolt hatást, és megfontolni a beépítését a közelgő termékekbe.
