Hmmm ...
Lehet hogy ez mindenkinek triviális rajtam kívül, de eszembe jutott egy lájvszéver dolog ...
Az "esett le" hogy tulajdonképp azon kódok 99% -a, melyek megengedik, megengednék hogy magasabb szintű nyelveken íródjanak,
és a közvetlen assembly optimalizálást nem igénylik ... azok valami futási időben nem változó, adatszerű dolgot írnak le,
adatszerű dolgot generálnak.
Tehát pld. eleddig egy LPT tábla generálást, egy csillagmozgás adattábla generálást, ilyesmiket ugye az SDCC -ben írtam le,
egyrészt azért hogy ne kelljen külső mondjuk C projektet felvenni, abban kimentegetni, a konstansokat duplán felvenni, nyilvántartani,
az egész olyan nehézkes ahhoz képest, mintha egyből a "játékba" írom ...
Aztán most hogy áttértem az assembly -re igyekeztem volna ugye azért az ilyen jellegű feladatokhoz nem elveszíteni a kényelmet és
a fejlesztési sebességet.
Ráadásnak most ráeszméltem, hogy pld. az LPT tábla (amit eddig eszembe nem jutott volna egy EP programnál nem "on the fly",
inicializálási időben generálni) ... az is milyen konstans egy dolog már ... gyakorlatilag az adott program konstansai teljesen leírják,
abból generálható, én még a memóriacímeket sem frissítem benne futási időben (mert lassú, még assembly -ben is), hanem vátogatok 2 előgenerált LPT táblát,
szóval az esetek 99% -ában minden ilyen dolog csupán az adott EP projekt konstansaitól függ, de valójában statikus dolog, fordítási időben leírható ...
És abban a fennmaradó részben ahol nem írható le fordítási időben ... na ott meg máris kell az assembly optimalizáció, ott nem megúszható ...
És csak a lehető legritkább (kockáztatom: a projektjeimnél zéró) esetben van az, hogy az adott kód futhat ugyan inicializálási időben, tehát nem kell
hozzá assembly optimalizálás, viszont nem írható le fordítási időben ... nem állítom hogy ilyen nincs, de nekem nem nagyon lesz ...
Szóval a következőt találtam ki:
Az EP projekt build -em egy komplexebb make "projekt" lett, több egymás után leforduló ÉS fordítási időben le is futó,
akár különböző nyelvi és technológiai megvalósítású komponensek összessége.
Ezek nálam nagyjából most úgy tűnik hogy a brass és a VC++ lesz,
de elvi szempontból tökmindegy, és változhat, bővülhet is.
A dolog úgy néz ki, hogy a programok konstansait pld. egy saját "makrónyelven" írom, melyet én rögtönöztem magamnak.
Attól lett "makrónyelv", hogy konkrétan C makrókkal dolgozom fel ezeket a konstansokat (majd szép lassan bővítem a makrókat, ahogy szükség lesz rá),
van olyan makró ami egy kommentet hoz létre a végső generált fájlokban (csak hogy ott is legyen komment, ne csak ebben az eredeti makró file -ban),
van amelyik ilyen vagy olyan típusú konstansot, satöbbit.
Valamint csináltam egy ilyen pársoros C++ programot, mely magába inklúdolja ezt a makró nyelven írt konstans file -t (rendesen compile time, #include -dal),
nyilván meg vannak írva benne a makrók, meg egyéb C++ progi, mely képes kimenteni a beinklúdolt file -okat a brass és a C++ (vagy ami még csak lesz később)
által inklúdolható formában.
Így akkor nem kell minden hülye nyelvhez és technológiához külön párhuzamosan nyilván tartanom egy adott EP projekt konstansait, közös adatait,
hanem generálódnak egy közös formából,
viszont nem is kellett normális programot írjak ami parszol valami saját formátumból,
vagy nem kell a konstansokhoz általános és bőlére eresztett formákat használjak mint pld. az XML,
valamint ki tudom használni a meglévő nyelvek makró funkcióit.
Persze a GNU világegyetemben ismert mindenféle texttranszformációs kütyükkel meg lehetne ezt oldani biztosan elegánsabban is,
melyben használhatnám a saját formát is, mégsem kéne parszereket hekkeljek, hanem egyszerű szabályokkal kifejezhető lenne ilyesmi átalakítás,
de részint nem ismerek ilyeneket, részint jó érezni, hogy a full C++ technológia ott van az ember háta mögött, és semmi nem tudja megakasztani ...
Miután ez a progi lefordult, mindjárt le is fut, és kiköpi magából a C++ és brass fordítók által megértett konstans file -okat.
Aztán a következő lépésben lefordul egy szintén kicsi, egy .cpp -s C++ progi (minden külön projektfile, meg ilyesmi nélkül, csak úgy commandline -ból),
mely inkúdolja előzőben generált konstans file -okat, és így meg lehet írni benne az LPT generáló kis C++ kódot, mely kimenti az LPT -ket egy file -ba.
Bármit változtatok a közös konstans file -okban, az tehát egyből egy módosult generált LPT file -t okozhat.
Aztán ugyanez a csillagok generálásával, majd ugyanez bármivel.
Az EP progi pedig mindent csak tölt és használ, semmit nem generál.
Így gyors is lesz a fejlesztés, kedvenc nyelve(i)men akármilyen kényelmesen írhatom őket,
az EP- n pedig még csak a helyet sem foglalják a generáló kódok, mindent oda töltök be,
ahol az valóban van az EP progi futása alatt.
Namost mindebben nincs semmi különösebb finesz,
azon az egy meglátáson kívül, hogy egy ilyen EP demo/game projektben kb. semmi nem olyan,
hogy inicializálási időben futhat, ezért nem kell mindenképp assembly optimalizálni,
viszont futási időben változtatni kéne a lefutást, és így nem lehet egyszerű adatfájlként betölteni.