Vlákno názorů k článku Optimalizace programů překládaných céčkovým překladačem cc65 pro procesory MOS 6502 od MilanV - Díky, pěkný rozbor schopností cc65. Je teď jasné,...

  • 29. 9. 2026 17:57

    MilanV

    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

  • 30. 9. 2026 8:41

    Dushino

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

  • 30. 9. 2026 9:51

    Pavel Tišnovský
    Zlatý podporovatel

    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.