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á...