Názory k článku Optimalizace programů překládaných céčkovým překladačem cc65 pro procesory MOS 6502

Takze se zacnou pouzivat globalni promenne, staticke promenne (i kdyz to v kodu neni videt) a nakonec instrukce zapisovane do __asm__. Z toho me plyne, ze na 6502ce je stale nejlepsi proste jit do assembleru, at uz ca65 nebo MAD assembleru. Nakonec ten MAD assembler je takovej privetive stredoevropskej (vsude polstina atd.), takze ten :-)

Pokud je pro danou aplikaci výkon úplně na prvním místě (a ne určité pohodlí při vývoji a ostatní výhody C), tak assembler je opravdu jediná možnost.

ani ne tak vykon, jako misto v pameti. Vsak ten kod bez optimalizaci je strasne roztahanej. Jako chapeme proc - zasobnik - ale stejne. IMHO driv ci pozdeji u jakekoliv aplikace pro 6502ku prijde na radu assembler ;)

Díky, pěkný rozbor schopností cc65. Je teď jasné, v čem jsou jeho slabiny a proč už minule nemohl vygenerovat lepší kód. On nemá vůbec vlastní optimalizaci kódu, tj. ani základní analýzu kdy se k čemu použije jaká hodnota v jaké proměnné. Viz ten příklad A=42, clc, adc #1. Tak teď už je vše jasné.

...kromě toho proč ho teda používat :)

Ale stejně mi to pořád vrtá hlavou: copak třeba Arduino nebo původní ESP má prostor pro obří zásobník a jiné "potřebné věci pro C"? A taky se na ně překládá. Podle mě to technicky jít musí, jen pro to asi není "trh" a nenašel se zatím dostatečný nadšenec...

Zkrátka souhlasím: assembler je na osmibitech nutnost, aby se tam člověk s kódem nějak vešel a nepřidělávalo mu to víc práce než pomáhalo. No jo, no - mašinky naše maličké, chudičké - ale milované! :)
(A je úplně jedno, jestli ZX Spectrum, C64, Atari... Svou "dějinnou úlohu" splnily všechny!)

29. 9. 2026, 18:00 editováno autorem komentáře

Neznám objektivní odpověďi, ale mám subjektivní odpovědi:
- Registrů u 6502 je fakt málo a tím se všechno dost komplikuje.
- Jestliže kompilátor přeloží inkrementaci jako CLC a ADC #1, znamená to, že v kompilátoru chybí peephole optimalizátor. A, samozřejmě, je pak otázka, jak tento kód optimalizovat, tj. jestli je možno přímo INC proměnná, nebo tu hodnotu PAK budeme potřebovat a je lepší LDX proměnná, INX - ale pak musíme řešit, jestli můžeme přijít o X.
Při analýze kódu Action! jsem pro podobné nedodělky měl pochopení. Action! překládá na stroji s málo RAM, má pomalé periferie i CPU. Přesto jsou, podle mě, schopnosti překladače úžasné. Na cross-compilery běžící na PC ale tato omluva neplatí - spíš to ukazuje na to, že C pro 6502 asi opravdu nikdo moc nepoužívá, proto jej moc nevyvíjí. Možná jej ale nikdo moc nepoužívá proto, že kvalita generovaného kódu není moc velká a nikomu se nechce do jeho vylepšování, protože to stejně nikdo moc nepoužívá...

Byly snahy přidat backend pro MOS 6502 do gcc. Takže by to využívalo všechny optimalizace, které v gcc existují (na úrovni mezikódu) a potom by se "jen" mezikód transformoval do instrukcí MOS 6502. Jenže právě to "jen" to IMHO zabilo, protože výsledkem byl zase šablonovitý kód.

Ještě přemýšlím o jednom nestandardním zdroji optimalizovaného cross-překladače pro osmibity: CP/M apod. Na tehdejších minipočítačích určitě něco měly, protože některé větší firmy tak vyvíjely hry pro osmibity. Takže sehnat emulátor minipočítače a v něm pustit cross-compiler C pro Atari :D :D

Cross-assemblery pro minipočítače existovaly a používaly se, třeba CAMAC, ale pochybuji, že by ve společnostech jako Atari nebo Activision používali překladač jazyka C pro 6502, pokud tedy vůbec nějaký existoval. Zato překladač jazyka Forth se používal určitě.

Díky, to je zajímavá informace. A jak tak o tom přemýšlím a ještě jsem si zjišťoval včera po internetu, ono se dost lidí nezávisle na sobě dostalo k názoru, že pro jakýkoli osmibit je Céčko zkrátka nevhodný jazyk. Takže věřím tomu, že raději použili ten Forth.

jj až na 6809 (ale to bylo z několika důvodů pozdě a moc draze) ty osmibity na céčko moc připraveny nejsou. To až dlouho potom AVR (pokud jsme pořád u osmibitů).

pro jakýkoli osmibit je Céčko zkrátka nevhodný jazyk

Tiež by som ako protiargument uviedol AVR8, kde som býval vždy skôr príjemne prekvapený, ako aj netriviálnejšie veci písané v C, vrátane trebárs nejakých dátových štruktúr a algoritmov k nim, to celé volané z interrupt handlerov a pod., vychádzajú po preklade stále relatívne kompaktne a efektívne; ten "wau faktor", čo všetko sa dokáže zmestiť do pár kB výsledného kódu.

Je to ale platforma s 32 všeobecnými registrami, 3 registrami pre indirect (+displacement) adresovanie, bez šaškovania s vecami ako "nultá stránka" pri MOS 6502, takže hej, z pohľadu C prekladača sú o dosť viac friendly. Plus teda zmysluplné toolchainy od začiatku zahŕňali GCC backend (a linker schopný efektívne eliminovať nevyužívaný knižničný kód), nie naivný minimalistický prekladač.

Jasně - to navazuje na mou otázku z dřívějška, že přeci pro Arduino funguje překlad Céčka normálně a optimalizovaně. Tak jsem si o tom něco málo našel a... A je to úžasné číst, jak navrhovali instrukční sadu a adresní módy rovnou dohromady s autory překladače C a architekturu upravovali podle potřeb kompilátoru... A i dál je to z pohledu "našich" osmibitů jako četba z budoucnosti - a taky že je, skoro 20 let poté (1978 vs. 1996). Ale dobře to udělali s tím AVR, všechna čest!

Já bych se 6502 trouchu zastal. Ono to "šaškování" s nultou stránkou byl docela dobrý nápad v době, kdy RAM (i v CPU) byla velmi drahá. Nultá stránka byla prý prezentována jako náhrada za interní registry, takže v tomto smyslu má 6502 256 interních registrů. Jasně, byl to z části marketing a přístup do RAM není totéž jako interní registry, ale aspoň něco. A jsem si docela jist, že právě tento přístup byl jeden z klíčových faktorů, který umožnil, aby byl 6502 tak levný a tím se rozšířil do domácností. Srovnávat AVR a 6502 prostě nejde - 20 let je v IT té doby ještě více, než 20 let v IT dnes. V době vzniku 6502 byl každý 1kiB RAM drahý, každé pouzdro drahé.. I proto byly obvody jako R6532 RIOT https://en.wikipedia.org/wiki/MOS_Technology_6532 a pro (nejen) domácí použití to stačilo.
C byl původně navržen jako "přehlednější assembler" pro psaní nízkoúrovňových utilit pro Unix. Myslím, že v době tvorby 6502 opravdu nikoho ani nenapadlo, že by někdo chtěl použít C pro 6502 ne tak ještě to na 6502 kompilovat a linkovat. O to víc vyniká fakt, že při návrhu AVR už tvůrci brali v úvahu i vlastnosti kompilátoru. A to je vývoj, a je to tak dobře.