Uf...!! Tak jo, tohle jsem teda nečekal, takhle podrobné ukázky kvality překladu. Super! Jen mi tam chybí víc zdůraznit pohled z roku 198{5-9}, tak ho zkusím dodat tady:
Když totiž čteme ty ukázky překladu v roce 2026, máme tendenci koukat na to stylem "tady to nezoptimalizoval úplně" - aspoň já jsem tak přistihl sám sebe :) Jenže tehdy šlo o něco jiného: máme vyšší jazyk ještě lepší než BASIC, ale padají z něj překlady svou délkou i rychlostí řádově blízké ručně psanému kódu v assembleru. V tomto pohledu je tedy nepodstatné, že je to třeba 1,5-násobek toho ideálu, protože např. z TurboBASIC, i TurboBASIC compiler(!), jsou o jeden až dva řády horší, tj. 10-100x !
A přitom se jedná o kompletní prostředí editoru, překladače a monitoru, co prý umí i trackovat program. Tj. použitelné i s kazetou! A ještě to umí v RAM najít místo pro zdroják i přeložený program (a ten překladač...) Já to snad budu muset vyzkoušet... I když předpokládám, že všechny ty triky uměla jen ta původní verze z cartridge, protože nějak tu paměť navíc "vyčarovat" musí. Verze, co jsem měl na kazetě, bude asi mít omezení.
V každém připadě, když touto optikou koukám na ty ukázky v článku, tak musím naopak smeknout všechny klobouky. To je něco neskutečného. Velká škoda, že jsem tehdy nesehnal pořádný manuál k tomuto jazyku...
O to víc díky, Pavle, za úvod a "nakopnutí" se na tento zajímavý jazyk podívat!
10. 9. 2026, 08:46 editováno autorem komentáře
Z pohledu roku 2026 musim rici, ze nejlepsi desitky let vyvijeny C prekladac (cross compiler!) pro Z80 (z88dk) produkuje stale prumerne 4x az 8x horsi kod (u netrivialni ulohy) nez to, co napises rucne a to nemluvim radsi o velikosti (co vsechno ti to prilinkuje). Ja mam prekladac Forthu (zase cross compiler!) co je 2x az 4x rychlejsi nez C reseni, ale... prumeru cisteho ASM proste dosahnout nelze. Kdyz narazis i na modernim CPU na casovy problem, tak i tam porazis moderni prekladac (aspon pro to sve konkretni CPU), kdyz se do toho poradne opres a venujes se tomu. Tam ti to ale bude hazet klacky pod nohy a na prvni pohled rychlejsi reseni bude pomalejsi, protoze nejake cache nebo spatne zvoleny pristup prochazeni dat atd. Spokojeny s prekladacem muzes byt jen do te doby, nez se podivas, co produkuje za kod.
Ten vysledek Action! je uzasny, ale klicovy bod pro uspech je spravne zvolit mnozinu toho, co to umi, aby to sedlo tomu CPU a jednoduse se to nahrazuje primo za kousky assembleru. Idealne aby to byl jen maskovany makroassembler. :D
Takove C ma proste dane, ze standardne uklada parametry funkci na zasobnik (rekurze vzdy povolena) a to Z80 efektivne nezvlada. Takze ma tezky handicap uz na startu, takze dodava specialni parametry, ktere meni standardni chovani (__FASTCALL__).
PS: Ten Basic muze byt i 1000x pomalejsi, nejen 100x, aspon na ZX, ktere patri v rychlosti mezi nejhorsi mezi 8bity (protoze treba ta podporovana mnozina obsahuje i to, ze cislo muze byt float nebo int schovany ve floatu a ty pokazde musis resit oba pripady a ty prevest ho na ten nejpomalejsi a ten spocitat.. :D ale zase to snizuje pocet tokenu, kdyz explicitne nerozlisujes int a float).
souhlas tak z 80%. IMHO cecko nikde nespecifikuje zadny zasobnik. To je jen implementacni detail a stejne se obchazi - dneska se parametry posilaji pres registry, pokdu to jde.
Ono se zasobnikem se blbe pracuje i na MOS 6502, asi i hur, nez na z80. Ale co, vsak mame nultou stranku...
Ak niekto necital clanok o MAC/65 assembleri tak pripominam, ze Action! pisali ludia ktori predtym napisali standardny Atari Basic, Atari DOS a aj MAC/65 assembler.
Chtěl jsem si vyzkoušet příklady, ale nechce se mi je přepisovat. Nevím jestli nedělám něco špatně, ale když zkusím odkaz na github tak tam není složka Action!, Ostatní programy v ASM... vidím
JB
Aha, vykřičník v názvu adresáře :-) Už by to mělo být dostupné, zatím zdrojáky v Action!. Vygenerované ASM soubory přidám později. Díky za upozornění.
Soubory jsou vidět, ale načítat mi do simulátoru nejdou. Hledal jsem kde je problém a našel jsem, že soubory stažený z githubu mají ukončené řádky "0A", kdežto soubor uložený z Actionu má řádky ukončené "9B". U jednoho jsem to zkusil ručně zeditovat a pak šel načíst.
Na počítači mám WIN XP a simulátor Atari800WinPlus4.1, Action mám v "cartidge"
12. 9. 2026, 18:28 editováno autorem komentáře
To záleží na emulátoru. Některé mají zařízení H: a potom i H1: nebo H8:. což je stejné zařízení, ale s ASCII konci řádků (provádí se překlad).
Pokud to ten emulátor neumí, tak nejjednodušší je:
tr "\n" "\233" <x.act >X.ACT
(raději používat velká písmena - to se líp zapisuje v Actionu při načítání).
Tak tenhle emulátor umí H1-H4, ale ASCII nebere nijak. Našel jsem v menu simulátoru nástroj, který by snad měl soubory upravovat, ale nějak to nefunguje. Nástroj tr "\n" "\233 funguje skvěle. S velkými a malými písmeny problém není, což asi bude Windowsem, který to nerozlišuje.
Ještě jsem si teď zkoušel jak na programy v Basicu. Pro sebe jsem si je ukládal pomocí SAVE a načítal LOAD. To má ale úplně jiný formát. Pak jsem si vzpomněl, že to jde taky pomocí LOAD a ENTER. Jen se opět musí upravit konce řádků.
Ještě jednu poznámku k TR:
Nejsem příliš zběhlý v používání příkazů Unixu/Linuxu, utilitu TR jsem dneska viděl poprvé (je to šikovný nástroj). V MS-Dosu nebo Windows není, přesto když jsem to napsal na příkazový řádek ve WIN XP, tak mi to hned na poprvé fungovalo. Jak je to možné? Hledal jsem a našel: nainstalovala se mi společně s AVR studiem (AVR toolchain) a ještě ke všemu je ta složka zařazená do PATH.
Action! som pouzival. Uz si nepametam, ci z cartidge, pasky alebo diskety. Bol brutalne rychly oproti basicu, ale narazil som tam na velkost pamete, vecsi kod sa mi uz nemestil spolu s celym actionom.