OldComp.cz

Nebylo by jednodušší rozchodit tohle? https://www.bell-labs.com/usr/dmr/www/primevalC.html

_________________
Plesnivý sýr z Tesca, zatuchlé kuřecí řízky z Albertu, oslizlé hovězí a myší trus z Lidlu.
Nákup potravinářské inspekce v ČR, říjen 2023.

66 MB a do /etc? tak to je neco hodne spatne...

Tam kde jsem to zatim potreboval pro preklad C pro Z80 (a jine male mrsky) jsem pouzil SDCC, to funguje celkem snadno out of the box, ale prijde mi tragicka kvalita vystupniho kodu . CP/M priklady ktere jsem teda nikdy primo nepouzil jsou na https://github.com/hkzlab/sdcc-cpm-example


Lide obecne pisi, ze Hitech C je na Z80 asi nejlepsi optimalizujici prekladac.

Binarky lze stahnout zde https://github.com/agn453/HI-TECH-Z80-C (jsou to CP/M programy, zadna multiplatformnost !!)

Spustit to pod Unixem jde pomoci https://github.com/agn453/ZXCC/ - to je jednoduchy emulator Z80+CP/M. Tady jsem naprosto selhal, odhalil jsem nekolik ruznych chyb (mych i autoru), a pak to vzdal, protoze ...

nakonec jsem narazil na https://github.com/serge-404/HI-TECH-C-V3.09 , ktery out of the box jde spustit na Windows, a zrejme i jinde. Originalni navod https://github.com/serge-404/HI-TECH-C- ... Z80DOC.TXT

(prekladac 'c.com' se spousti jako 'cpm -a c hello.c' - vytvori 4kB dlouhy program , ale jen diky prilepeni knihoven, vlastni prekladany kod neni az zase tak tragicky jako sdcc. Dalsi parametry: -S udela assembler, -O optimalizace. )




Zdrojaky knihoven Hi-Tech C jsou k nalezeni zde https://github.com/tsupplis/zxcc-htc

mne pred casem fungovalo tohle>
viewtopic.php?f=81&t=5794#p95880
nyni https://github.com/spectrumcomputing/li ... llation.md



K tomuhle bude taky tady nekde vlakno...
https://github.com/oldcompcz/HiSoft-C

_________________
// na co myslím, když sedím u oldkompů: režim

HI-TECH C funguje na CP/M i v emulátoru na Windows.
https://github.com/serge-404/HI-TECH-C-V3.09

Na Linuxu se to dá provozovat pod emulátorem:
https://github.com/udo-munk/z80pack

Mám to popsané zde:
http://www.valachnet.cz/lvanek/diy/rc2014/index.html#RTM_Z80

... ale rozjet to bylo složité jak žebř. Pokud chceš tak to celé spakuju a dám to na FTP.

Ale nejpohodlnější cesta je z88dk na Windowsech.

_________________
RC2014 Pro, RC2014 LittleBro, RC2014 Zed, RC2014 Mini

z88dk jde uz instalovat snadno ze snapu.

Instalace je ale jen zacatek, pak se clovek musi prokousat tim, proc mu nejake veci nefunguji a jak vubec spustit kompilaci.. .)

Mezitim jsem si napsal vlastni prekladac vyssiho jazyka do Z80. Dva az ctyrikrát efektivnejsi nez co dokaze C. Nez C bych spis doporucil dnes Boriel Basic prekladac, ktery je asi 2x lepsi jak z88dk.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

U HiTech C je dost velká brzda předávání parametrů přes zásobník:

_________________
RC2014 Pro, RC2014 LittleBro, RC2014 Zed, RC2014 Mini

Jo a HiTech C umí klíčové slovo 'register' pro max jeden parametr.

_________________
RC2014 Pro, RC2014 LittleBro, RC2014 Zed, RC2014 Mini

C to resi elegantne (ale neefektivne na Z80) pres ten zasobnik, protoze tim je zaruceno ze jde provest kdykoliv rekurze. Bez ohledu zda ji pouzijes nebo ne.

Z80 ten zasobnikovy ramec moc neumi. Nebo umi relativne snadno pomoci IX nebo IY, ale ty jsou fakt pomale a zabiraji hodne pameti.

Boriel Basic to resi pres pevne ukazatele na pametove mista, co je kratsi a rychlejsi, ale nezvladne to rekurzi.

Forth je na tom mozna nejlepe, ale zase potrebuje 2 zasobniky a Z80 umi jen jeden a druhy musis nejak emulovat (stacila by jedinna rychla instrukce " ex SP,SP' "). Z tech 3 jazyku je na tom Forth asi nejlepe. Bude delat suverene nejkratsi kod. Nebude nejrychlejsi, protoze bude pro kazdou i nejjednodussi "instrukci/slovo" provadet nejake volani (asi to jde resit v kritickych mistech pres assembler nebo immediate slova, pokud to chapu spravne tak by meli byt primo vykonany). Ale je asi nejtesi z pohledu programatora. Rekl bych je to skoro stejne tezke jako assembler, jen mnohem rychlejsi na psani.

Nejlepsi je se asi naucit ten assembler... .)

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

sdcc 4 umi predavat argumenty v reg - zde https://www.msx.org/forum/msx-talk/deve ... rogramming

zkusil jsem prelozit vprintf pomoci ruznych prekladacu (sdcc 3, sdcc4 + optimalizace, hitech C,Small-C/Plus z88dk), muzu to sem hodit pro srovnani. Jsem ale dost zklamany.

z88dk z gitu se mi na novejsim aktualizovanem ubuntu (bullseye/sid) celkove prelozit nepovedlo (nezkoumal jsem proc, po desatem+ problemu jsem to vzdal), ale dostal jsem se alespon do faze ze byl prelozeny Small-C). Se "stable" tarballem jsem skoncil u uplne banalnich chyb, kdy bylo jasne, ze autori dlabou jak na bugreporty tak na kvalitu sve produkce ("mne to funguje tak co").

sdcc 4.3.0 proslo bez problemu. Mohu sem dat postup jake jsou dependencies.

Pokud zacnes pouzivat registry jako uloziste dat tak jsi zrusil rekurzi. A nejen ji, ale i volani fci z fci. To bude fungovat jen u tech poslednich fci. Predstavuji si to jako listy stromu, nevim jak se tomu rika odborne, proste posledni "vetev".

V registru podle me muzes mit bezpecne jen navratovou hodnotu jak je to vlastne v C delane.

Takze zadne do IY dam navratovou adresu ("pop IY") tim si uvolnim dalasi data na zasobniku a pak to ukoncim pres "JP (IY)". Tohle funguje jen u "listu".

U Forthu to nevadi, protoze je to cele delane na tom ze program (operace) bezi nad TOP a NOS a kazde slovo ma jasne definovane co se stane. Plus pak i programator musi volit ten algoritmus tak aby byl pro to efektivni. Je to mene abstraktni.

Normalni zasobnik ma proste hw podporu v Z80, aby byl efektivni pro pristup k posledni polozce jak to ma Forth.

PS: Jak jsem rekl to z88dk muzes naistalovat pres "snap store".

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Tohle je nepravdive tvrzeni ze dvou duvodu, vetsina ABI calling conventions https://en.wikipedia.org/wiki/Calling_convention nejen ze definuje modifikovatelne registry, ale pro spoustu pripadu neni nutne ani delat stack-save (a chytry prekladac na to prijde).

Moje zklamani ze sdcc ale nabyva, treba tenhle kousek kodu, kdyz tam dam na konci %64 misto toho &0x3F, tak to hodi volani na nejake signed modulo (nepozna ani to, ze muze binarni modulo udelat sam).

do {vram[cursorpos++] = ' '; } while (cursorpos&(64-1));

Nebo ve vysledku hrabemi prehazuje tu promennou cursorpos mezi registry a pameti (load-modify-store-load-use-load-modify-store-...), prestoze tam nic nedelam a bohate by mu stacilo hl+de .

A to jsem nadaval jak GCC pro RISC-V neumi optimalizovat .

To me teda vysvetli jak napriklad u fce jako je Fibonaciho posloupnost definovane (neefektivne) rekurzivne ti pomuze ze das vstup do registru...

To ti prece dost rychle dojdou.

Nebo ze si uklidis navratovou hodnotu do registru. Pak uz nemuzes pouzit ten samy registr na ten samy trik. Takze to jde jen pro volani "listu".

Ja to fakt nechapu. Definovat ze neco bude v registru pomuze jen pro ty listy. Popripade pro zacatek fce nez je z ni volana dalsi, pokud uz to nebude pak pouzito.

PS: To ze to dela kraviny je dusledek toho ze je ten program rozdelen na co nejmensi casti a pak znovu slepen... a ta komunikace (predavani informaci) mezi temi castmi je slaba, nebo zadna (minimalni co je nutne).

Taky to mam v mem prekladaci... musel bych vytvorit uplne novy system a pro kazde slovo to dusledne dodrzovat aby to fungovalo. Predavat si podrobne informace pro kazdy registr co v nem je a co je na vystupu. Informace nejen co je tam za hodnota, ale i jestli je to jen smeti a nebo co to znemna, napr. ze je to hodnota citace smycky "i". Ze ho ma napr, reg BC a jeste je na zasobniku nebo v pameti na te a te adrese. A ted psat kazde slovo/fci pro vsechny kombinace.

Pokud napriklad potrebuji drzet aktivne 3 hodnoty, tak treti je uz na zasobniku a kdyz ji nactu do BC (a zase hned ulozim aby se neztratila) tak dalsi slovo ktere muze byt hned za tim i kdyby prvni nezmenilo BC se to bude snazit provest znovu.

Kdyby dalsi slovo vedelo ze treti polozka je zaroven v BC, tak ten kod bude vypadat jinak.

Me reseni optimalizace bylo asi to co se mozna nazyva optimalizace "kukatkem". Pro nejakou castou kombinaci slov, ktere nejsou vzajeme moc efektivni proste udelam nove slovo a rucne napisi lepsi kod.

To funguje celkem dobre pro maly pocet kombinaci, jinak ten pocet roste exponencialne, pak je lepsi kdyz to jeste umi seskladat z informaci co by dostal, protoze pocet registru je omezeny.

PPS: %64 me uz trapi nejmene, protoze to muzes ovlivnit sam pres & 63, takze to mas pod kontrolou. Horsi je podle me to co neovlivnis.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH

Uplne postaci si registre pri rekurzivnom volani odlozit na zasobnik. Vznikne tym taky nativny stack-frame ktory uz rekurziu zvlada.
Napriklad funkcia ma parametre v registroch BC,DE

Jednak se daji ulozit na stack, pripadne do jinych dalsich registru (kerych v Z80 moc neni, ze? ale treba u ARMu je to bezna praxe, ze napr u BLR se LR ulozi do jineho registru, tzn. pak na stacku neni ani return adresa druhe predchozi fce), no a nakonec jsou algoritmy, ktere tohle vubec nepotrebuji - a neni jich malo.

Neschopnost optimalizovat veci typu %64 na &0x3f komplikuje citelnost a parametrizovatelnost kodu. Nejaka snaha asi byla, protoze jednoduchy pripad to zoptimalizuje spravne: https://godbolt.org/z/xWxxTxPxT ??

Tady je postup jak zkompilovat sdcc na relativne cistem ubuntu:



a preklad meho barebone kodu: