Názory k článku Minimalistické překladače jazyka C: tcc a Chibicc

jako zajimavy vtipny prekladac mi prisel projekt, ktery generuje jenom/prevazne move instrukce.

nekde jsem videl, ze typek si udelal CPU, kde cela ALU je jen jedno hradlo

Vzpomínky, vzpomínky... Kdysi v 90. letech jsem toužil po překladači C a objednal si (tuším přes tehdejší časopis Bajt nebožtíka L. Zajíčka) na disketě nějaký shareware C překladač pro DOS - byl omezený, plná verze se měla platit. Pak jsem si s velkou slávou za tehdejší strašlivou cenu cca 2300 korun koupli krabici s Borland C++ 3.0. No a pak přišel na můj desktop po čase Linux a měl jsem vše zdarma (gcc, egcs atd.).

Od C (i C++) jsem utekl, ale nostalgie zůstala.

ja jsem napsal bakalarku v DJGPP, to byl gcc pro DOS. Tehdy to melo strasne pomalej build, ale delalo to 32bitovy aplikace bez obfuskaci, ktery mel Borland C (pro DOS). Taky byl k dispozici Watcom pro DOS, ani nevim, kdo a kdy mi to dal, ale melo to v sobe stary Vi (editor) :)

Watcom byla legenda. Umožňoval přes extendery využít veškerou paměť v chráněném DOS režimu. U grafických programů, her se chytil hodně.

pamatuju jak jsem a kolegove zkouseli kdysi intelacky kompilator pro c a fortran v linuxu a bylo to rychlejsi i o 20%.

mam dojem, ze kdysi i linuxove jadro prekladali intelackym kompilatorem a fungovalo to.

jo a ted se mi vybavil ten cacheovaci zapcc, mate nejake info a zkusenosti s jeho rychlosti?

Je otazka, jestli by garbage collector mel byt soucasti jazyka a nebo ne. Spousta bezne funkcionality take neni definovana primo jazykem, ale treba v POSIXu. Nekolik takto implementovanych GC je pro C k dispozici, nejznamejsi je boehmgc (bdwgc), ktery vyuziva treba Inkscape, PyPy nebo Unity.

tyjo tezko rict. u jazyku, ktere moc neresi, kde se objekty vytvari, to asi jde. U cecka je to horsi, to uz ma ve specce zbytecne podrobnosti AFAIK

Tak zrovna ten boehmgc muze fungovat i v modu, kdy kompletne nahradi malloc, takze se pak nemusite starat ani o uvolnovani pameti naalokovane knihovnami, ktere nebyly pro alokator napsany. Samozrejme jen za predpokladu, ze k uvolneni vsech zdroju neni potreba provest jeste nejakou dalsi operaci (treba zavolat close()).

no jasne, ale porad se do toho bude plest omezeni jazyka. Prikad, alokace v ramci funkce v cecku na zasobnikovem ramci a vraceni ukazatele - to je proste spatne, kdezto v jazycich typu Java nebo Go se to neresi (v Jave proto, ze je vsechno reference na heap nebo primitivni hodnota, v Go proto, ze to kompilator odhali a neda tu oblast na zasobnik, ale na heap).

to me na zacatku v go leknulo, ze funkce vracela treba:

return &NejakyObjekt;

pak jsem zjistil, ze go samo urci, ze to patri na heap a vrati spravny ukazatel.

Problém je, že Boehm GC neví, co je pointer a co není. Takže se může stát, že uvolní data, ke kterým se jde ještě dostat, nebo naopak data, která měl uvolnit neuvolní třeba jen proto, že někde jinde je int, co má hodnotu shodnou s adresou.

aha, to je tedy zajime chovani s tim intem. Musim se na to podivat, to bude asi hodne velky hack ;)

kdyz je dost pameti tak se mi libi naalokovat si nejakou pametovou oblast, v ni si delat male alokace a neresit memory leaky a jen hlidat vymazani te oblasti.

To už fungovalo někdy v Pascalu 7 - stačilo označit označit počátek hromady (Heap) a na konci ho vrátit zpět. Je trochu (hodně) nepotěšující, že se správa paměti musí řešit ještě dneska.

To je tím, že správa paměti (a zdrojů celkově) je hodně složitý problém. A strategie, co dává smysl v nějakém kontextu, může být jinde mizerná nebo úplně nepoužitelná.

Tohle je docela dobrý a rychlý způsob u webových serverů, kde se taková oblast zřídí per request. Nebo programů, které zpracovávají eventy, tam se alokuje per event a po zpracování eventu se celá oblast uvolní. Případně her, kde se to může dělat per frame.

Nebo různých parserů, atd... je to naprosto běžná věc.

Takhle funguje management paměti v Postgresu. Je to nadstavba nad malloc - která vytváří hiearchii tzv paměťových kontextů. palloc alokuje paměť z vybraného nebo aktuálního kontextu, pfree může paměť uvolňovat. Paměťové kontexty mají definovanou životnost - transakce, query, výpočet řádku, výpočet výrazu. Na začátku je náročnější na to zvyknout - musíte vracet data ve správném kontextu, pak to funguje jak víno.

Hlavně je to relativně jednoduchý přímočarý mechanismus bez jakýkoliv jednoduchých nebo složitých (chytrých) heuristik. Jednoduché, ale chytré a roky s tím nejsou žádné problémy.

fajn článek
Chibicc tedy nejspíš moc praktických použití mít nebude. Maximálně jako reference.
Tcc se myslím využívá celkem často u toolingu prog. jazyků které kompilují/tran­spilují do C. Vlang ho používá určitě a myslím že i nim.
Hlavně pro windows uživatele to má výhody. Pokud jim chcete poskytnout vývojové nástroje tak než jim psát dokumentaci jak instalovat překladač z Visual Studia, tak jim prostě do zipu přibalíte i malinkou binárku tcc a pro vývoj je to naprostá pohodička.

AFAIK normálně se s Nimem používá GCC nebo Clang. Případně jde použít Zig jako C překladač pro cross compile.

ano s tím NIMem ne. Tam doporučují ať si lidé nainstalují GCC/Mingw pro Windows. Asi aby mohli rovnou práskat i produkční kód i na windows, to je s tcc nic moc jak je v článku.

nim těch backendů má celou řadu, tcc je jeden volitelných, je podle mě také ten nejrychlejší z nich, kdysi jsem zkoušel zig cc, ale to byla pomalost nad pomalost.

Mám rád tyhle komunitní věci, vlang je skvělý jazyk, z tcc těží jak to jde, škoda, že jeho compiler ještě pořád hází spousty syntax error, segmentation failů. Další zajímavá věc nad tcc je třeba https://bellard.org/jslinux. Z těch větších věcí je na něm třeba založený GNU Guix.

Ano, ten jslinux - to je založené na další jeho hodně populární věci - javascript engine https://bellard.org/quickjs/ malinký, embeddovatelný, umí es2023, a můžete s ním javascript "zkompilovat" do binárky. Prostě pecka
Ten chapík umí zajímavé a užitečné věci v C, co jsou ve výsledku většinou jedna malinká binárka, kterou pustíte všude.

21. 3. 2024, 21:12 editováno autorem komentáře

já toho chlapíka nechápu, je schopný tyhle projekty vyplodit za pár měsíců a jsou geniální. I qemu byl jeho miniprojektík.

alternativy jsou fajn i proto, ze maji trosku jiny memory layout. Takze chyby v pointerech, co muzou tise prochazet na GCC (napriklad), nepujdou na tcc a naopak. Takze asi neni zadna chyba si appku zkusit prelozit ruznymi prekladaci a otestovat (a nebo slepe verit Valgrindu;)

Tcc jsem pouzival pro opakovatelny/au­ditovatelnou binarku na vyrobu klicu kdy se auditoval i puvodni compiler (certifikacni pozadavky). Velka vyhoda je prave jednoduchy vystup, jednoducha auditovatelnost compileru i vysledneho spustitelneho kodu bez jakkekoliv optimalizace vysledne binarky.

V pedagogicke praxi to ma vyhodu ze na vysledne binarce dokazete studentum vysvetlit na disasembleru co se vse pri prekladu deje. A tim jak je ten preklad "hloupy" tak se neztratite v preoptimalizovanem kodu.

takze tcc nedela vubec zadne optimalizace?
kdyz je v c smycka, tak zustane i v assembleru?