Názory k článku Překladače jazyka C pro osmibitové domácí mikropočítače Atari

Takže jestli to porovnám s Actionem, tak je to céčko vlastně horší že? To nezní jako moc velký pokrok :)

Tak já mám díky tomuto seriálu vlastní mínění o celé sadě nástrojů *65 právě s ohledem na jejich "kanónovrabcovost", ale to se týká spíš toho nastavování okolo - samotný překlad bych čekal kvalitní. Obzvlášť ten pokus s peek() mě dostal, protože definice makra peek() je přesně taková jaká se použila předtím přímo v tom překladu s pointrem. Takže z toho je vidět, že optimalizace závisí na způsobu zápisu a ne na analýze výsledného céčkového kódu po vyhodnocení maker.

Takže nejenže to není pokrok od Action!, ale není to ani pokrok od primitivního překladače, který se vešel do 16kB i s editorem a monitorem a knihovnami(!) a běžel na počítači s 1,78MHz CPU a 64 kB RAM k "všemocnému" PC s Linuxem či Windows s víc než tisíckrát rychlejším CPU a cca milionkrát větší RAM.

Tady bych naopak čekal triky a optimalizace, na které jsme "ručně" neměli šanci v tehdejší době přijít.

24. 9. 2026, 10:50 editováno autorem komentáře

no je to tak. A je to ještě horší, protože další alternativy (https://github.com/ilmenit/CC65-Advanced-Optimizations/tree/master#CC65-alternatives) jsou na tom stejně špatně.

Takto: udělal jsem oslí můstek k pokračování článku, kde se výsledek cc65 vylepší. A v tom je ten paradox - aby to člověk dokázal vylepšit, stejně musí znát assembler MOS 6502. Prostě na moderních architekturách se rozdíl člověk/překladač dost smývá, ale na MOS 6502 jasně vítězí neumělá inteligence :-)

Díky za ten odkaz. Ona to asi fakt není sranda, překládat obecné Céčko do tak odlišného světa jako je MOS 6502. Já jsem spíš narážel na to, že tady evidentně neudělal překladač optimalizace toho výsledného assembleru, nezávisle na tom, odkud vznikl. A to ani ty obecné, co jsou už na "prvním levelu optimalizace" u běžných překladačů. Vezměme si to wsync() z posledního příkladu: (přidal jsem čísla řádků, abych se mohl odkazovat v textu)

10 lda $0014
20 jsr pusha
30 ldy #$00
40 L0044: lda (sp),y
50 cmp $0014
60 beq L0044
70 jmp incsp1

1. nejdřív optimalizace smyčky: jelikož v jejím těle se nemění ani A, ani Y, ani (sp), tak posunu lajblík o instrukci dál, na řádek 50
2. řádky 20-40 teď dělají akci "ulož a znova totéž načti" a zároveň vidím, že uložená hodnota se dále nikde nepoužívá - celý nadbytečný kód smažu
3. pokud jsem ho smazal, nesmím měnit zásobník jako by tam to ukládání na něj pořád bylo - smažu řádek 70 a nahradím ho běžným RTS

Výsledek:

10 lda $0014
50 L0044: cmp $0014
60 beq L0044
80 rts
A to už není tak špatné, ne? A to jsem provedl, podle mě, méně než je běžná sada úkonů pro -O2 v gcc. A nad assemblerem, kterého jsem se neptal, čeho překladem vznikl, prostě obecně.

Síla CC65 je zkrátka trochu jinde než v perfektně optimalizovaném kódu. Podpora většiny vlastností jazyka C, oddělený překlad, dobrý assembler, velmi dobrý linker, robustní běhová knihovna pro několik typů počítačů.

Samozřejmě, ne všechno musí být užitečné pro každý příklad užití. Pokud vyvíjím hru, tak je mi robustní běhová knihovna s plnou (a velikou) implementací printf() spíš k ničemu. Zato se ocení inline assembler a celkem jednoduchý způsob jak kombinovat moduly v assembleru a v céčku.

Ono u mě to asi narazilo na klasický problém tzv. nevhodně nastaveného očekávání.

Mně vždycky přišlo (už od těch 80. let), že problém v omezení stroje není ani tak u výsledného kódu jako u toho všeho, co vzniká mezitím při překladu a kde potřebujeme analyzovat kód a dělat nad ním různé optimalizace. Proto je to to skoro jediné a určitě to hlavní, co bych od něj chtěl: využít sílu "většího brášky" alias PC na pořádnou analýzu kódu, kde nás nebude omezovat žádných 64 kB paměti, a právě získat pak výsledný kód, ze kterého bude profitovat ten "slabší brácha" atárko: velikostí i rychlostí.

Kdyby cc65 (nebo kdokoli jiný) takové výsledky měl, ale potřeboval by k nim mou součinnost jako obskurní konfigurace nápověd rozložení paměti apod., rád to pro něj udělám. Jenže cc65 ty obskurnosti chce a výsledky nemá.

Action! je primitivní překladač a linker v jednom. Běží na tom samém Atari, kde už je v paměti, kromě všech vyhrazených zón pro ROM apod. i zdroják programu a jeho překlad a také knihovny runtime. Proto nemůže být překlad ani zdaleka dokonalý. Od překladače a linkeru na PC bych jako první tedy čekal, že někdo začne tohle optimalizovat i díky tomu, že má moře prostoru, kam může natáhnout všechno najednou, projít to, analyzovat a optimalizovat na straně překladače i linkeru.

Samozřejmě je otázka, jak moc jde tohle všechno udělat pro jazyk C. Ale zase: nikdo neříká, že s takovouto výpočetní silou pro překlad se máme držet nějakých pevných neoptimalizovaných vzorců primitivního překladu - od toho je tolik desetiletí praxe psaní překladačů a linkerů... Tak v mnoha případech nemusíme vůbec použit ten pořád zmiňovaný zásobník apod.

Technicky to jistě jde, ovšem vývojářů schopných něco takového naprogramovat podle mého názoru není až tolik. Navíc by to znamenalo angažovat se v retro projektu, který není komerčně významný. A Céčkových vývojářů pro staré platformy (s procesorem z rodiny 6502) je pomálu. Ti opravdu dobří jedou v Assembleru a C je tolik netrápí a nechybí jim.

Mimochodem, co je, proboha, rutina "pusha", že se na ní volá JSR?? Oni se stydí napsat PHA do normálního kódu nebo zneužívají zásobník nějak magicky, že neukládají na jeho vrchol a používají to adresování (sp),y ??

Evidentne nepouziva stack, ale vyhradil si ZP adresu, takze pocitam ze PSHA udela neco ve smyslu dec zp/zp+1 + sta (zp) ... To je tak jediny, co mi dava smysl.

Udelat PHA + TSX + LDA $00FF,X (nebo jak mu vyjde offset) nicmene muze. Predpokladam, ze chce obejit omezeni 256 bajtu na stack.

P.

24. 9. 2026, 12:32 editováno autorem komentáře

Predpokladam, ze chce obejit omezeni 256 bajtu na stack.
Aha, to bude ono - proto ta celá magie. Díky.

To je ale šílená snaha -vlastní stack na stroji s už tak totálním nedostatkem indexových registrů... A přitom stejně nepokryli ten problém úplně a musejí uživatele omezit, že např. nemůže předávat typ record hodnotou nebo ho funkce vracet... To už raději měli to omezení přijmout jako v Action! a byl by klid...

Ale pak by se zase neblížili Céčku tak jak by asi chtěli.

Existuje jedna potenciálně zajímavá alternativa - překladač KickC, který těch omezení má víc, ale měl by generovat lepší kód. To je ale jen teorie, v praxi bych třeba musel vzít některou z existujících her napsaných pomocí CC65 a upravit ji pro KickC.