PC FAND®

V květnu 2020 se mi podařilo přepsat všechny původní soubory *.PAS do C++, kromě kódu v ASM.
Při prvním pokusu o přeložení hlásil překladač přes 15 tisíc chyb. Ty se postupně podařilo opravit, nebo některý kód zakomentovat.
Překlad se nakonec v sobotu 9.5.2020 v 10:03 povedl.
Následovaly pokusy o otevření souborů RES a CFG. A byly úspěšné
Aktuálně po spuštění naběhne úvodní obrazovka PC-FANDu a dá se pohybovat v menu.

Dnes se mi podařilo zprovoznit i nápovědu. Docela jsem se s tím natrápil, přitom to byla taková blbost. No prostě C++, na rozdíl od Pascalu, zná = i ==. A jsou brutálně odlišné.
- nápověda v úvodním menu se zaktualizuje, až když uživatel klikne mimo okno - nutno dořešit
- editor téměř nefunguje, s tím bude ještě hodně práce Podařilo se mi i načíst INST.RDB, ale pak to při kompilaci skončí při zapisování zpět do souboru.
Ke spuštění je nutné mít v adresáři i původní FAND.RES a FAND.CFG

Po úspěšném spuštění úlohy INST.RDB se pokouším o zprovoznění úlohy UCTO2020.RDB.
Při počátečním spouštění dochází k načítání bloků instrukcí a k jejich překladu. Těchto bloků je přes 600.
Už se mi podařilo úspěšně zpracovat cca 80 těchto bloků, ale pak jsem se zastavil na instrukci "lproc".
Tato instrukce je totiž z Prologu a ten jsem neměl v této fázi vůbec v plánu přepisovat. Ale budu muset.
A možná můžu napsat "naštěstí budu muset". I když se jedná o velice obsáhlý kód, kde je zase spousta práce s pamětí, tak na druhou stranu je to velmi zajímavá problematika.
Taková ta predikátorová logika, termy atp. Přesto, že jsem to měl před rokem v Úvodu do teoretické informatiky na VŠB, tak si z toho moc nepamatuju.
Mám ale obavu z toho, že ucto2020.rdb bude vyžadovat i práci s grafy, takže bude nutné toto nějak obejít.

Podařilo se přepsat RDPROLG.PAS i RUNPROLG.PAS (ale nefunguje tak, jak by měl ...) a po nějakých dalších úpravách se podařilo zkompilovat celé účto 2020.
Při spuštění ale dojde k problémům s načítáním lokálních proměnných (LocVar). Zatím se mi nepodařilo pořádně rozluštit, kde ty proměnné vlastně sídlí
Kompilace celého účta na 2 GHz jádru trvá asi 20 vteřin a sežere 100 MB RAM. Ale to mě zatím netrápí.

Stále se snažím přijít na to, jak je to s těmi LocVar, ale snad už se to brzo podaří. Mezitím jsem přepsal některé původní pascalovské recordy do tříd v C++. Tím značně klesla paměťová náročnost a po zkompilování účta je to nyní 22 MB.
Opravil jsem i generování řádkových textů (náhrada za printf v C++, který (asi) píše jen bílým písmem na černé pozadí).
V úloze INST se tedy nyní správně zobrazí 1. řádek:

Pokračuji v pokusech na spuštění Účta. Problém je v zápisu hodnot a jejich čtení v souborech, protože data je potřeba nejdřív transformovat do potřebného formátu. Ale už je postupně i něco vidět na obrazovce
V současné době program padá na zápisu do souboru UCTO.000.

Po delší době jsem zaznamenal další pokrok. Účto je rozděleno na moduly, při startu se začne načítat MODUL01 a ten se opět kompiluje. Všechny ty kompilace trvají dost dlouho, takže to významně zdržuje debugging. V této chvíli se nedaří celý modul zkompilovat, spadne to na načítání Add do CFile, což vlastně ani pořádně nevím, co je. Zřejmě tvorba nějakých statisticky, sumářů nebo něčeho takového.
V PC-FANDu je použit příkaz LIKE, který říká, že daný popis souboru má vycházet z popisu jiného souboru. Tyto popisy jsou ve zkompilovaných souborech. Načítání těchto souborů je ovšem dost složité, mám jej rozpracované, ale dopsat je bude trvat ještě dlouho. Proto jsem napsal metodu, která objekt původního souboru zkopíruje. Ještě je nutné dodělat kopírování FrmlElem - není to složité, ale je nutné nejdřív zjistit typ a podle toho dynamicky kopírovat správný objekt.
Velkým oříškem bude práce s indexovými soubory - to je spusta stávajícího ASM kódu a přepis bude hodně bolet. Nejradši bych se celé práci se soubory vyhnul a naimplementoval to např. v SQLite. Jenže primárním cílem je kompatibilita, aby bylo možné bez jakýchkoliv změn spouštět úlohy pro PC FAND 4.2.
Dost by pomohlo, kdyby bylo možné se podívat do TP debuggeru, co se tam děje. To ale nejde ...

Tak po delší době se podařil trochu větší pokrok. Bylo nutné předělat práci s lokálními proměnnými v uživatelských funkcích. Díky tomu, že se mi podařilo sehnat knihu PC FAND krok za krokem, jsem si mohl přečíst nějaké detaily o tom, jak funguje samotný PC FAND a také jak by měly přesně fungovat některé příkazy. Děkuji tímto ještě jednou p. Vladimíru Valdovi za to, že mi ji věnoval; je jako nová.
Postupně se tedy podařilo přeložit i MODUL01 v Účtu a program hlásí při startu "SPUŠTĚNÍ PO HAVÁRII"
S ohledem na to, že celá kompilace Účta vč. tohoto modulu trvala 1,5 minuty, rozhodl jsem se, že už v této fázi budu řešit profiling.
Kompilace vytěžuje po celou dobu 1 jádro procesoru na 100%. Hodně času zabírala práce se soubory na disku. Proto jsem se rozhodl naimplementovat cache, kterou originál PC FAND používá. Jen tedy trochu jinak, protože nemám problém s operační pamětí. Na té se to konec konců téměř neprojevilo.
Pokud spustím RELEASE, tak se načte info o havárii za 6 vteřin, což je úžasné. Zabírá to celé 31 MB v RAM.
Pokud spustím DEBUG, načte se obrazovka za 45 vteřin (tedy za polovinu původního času) a potřebuje 49 MB RAM.
Takže prapůvodní myšlenka o nutnosti ukládat zkompilovaný kód je asi zbytečná. Předpokládám, že po nějakých optimalizacích se těch 6 vteřin v Releasu podaří ještě o něco málo srazit a tento čas už snad nikoho nezabije
Jak je vidět, jsou tam chyby (některé schválně). Rozměr obrazovky je 80x25, větší jsem zatím nezkoušel.
Teď je nutné dořešit práci s index. soubory, jinak se to asi dál nepohne. A to bude na dlouho ...

Před nějakou dobou jsem přepsal metodu "EqualsMask" tak, že využívá regex.
To se samozřejmě projevilo (negativně) na nápovědě, která přestala fungovat.
Posupně ladím přepis původních masek, které vstupují do metody tak, aby odpovídaly regexu.
Např.
. -> \.
* -> .*
{ -> \{
většinou jde právě o uvedení lomítka před znaky, které jsou operátory v regexu.
Navíc se teď nerozlišují velká/malá písmena
Takže nápověda opět funguje, ale předpokládám, že to nebude úplně všude.

Tak pokud by chtěl nějaký odvážlivec něco otestovat, je tady k dispozici pokusná verze, která toho zatím moc neumí.
Hlavně totiž neumí pracovat s indexovými soubory a to je hodně velké omezení. Ale výstup už vypadá docela věrně: