Ez egy T530-as laptopon készül, azaz momentán i86_64 alatt használható, vagy a franc se ismeri ki magát azon, hogy kell ezt írni mert van egy rakás jelölése ezeknek a platformoknak. Szóval Intel procis gépeken, 64 bites rendszeren. De tekintve hogy ez egy interpreter, emiatt simán meg lehet csinálni bármi más platformra is könnyen, amennyiben gondoskodunk arról, hogy az általa kezelt típusok bájtmérete megfelelő legyen. Ezek a következőek:
- mutatók: 8 bájt
- unsigned és signed char: 1 bájt
- unsigned és signed short int: 2 bájt
- unsigned és signed int: 4 bájt
- unsigned és signed long long: 8 bájt
- float: 4 bájt
- double: 8 bájt
- long double: 16 bájt
Szerintem ezek mindegyike megoldható 32 bites gépen is, legfeljebb ott ki lesz hagyva a long double, de talán az is összehozható. A mutatókkal se lehet nagy gond, mert a 32 bites pointer simán belefér a 8 bájtba, max nem lesz kihasználva annak minden bájtja.
Ami a függőségeket illeti, egyelőre olyan neki kvázi semmi sincs, kivéve azokat a cumókat amik a g++ fordítónak úgyis eleve kellenek, gyakorlatilag eddig csak ezek a header állományok kellettek nekem ebből is mindössze:
sys/time.h
time.h
stdlib.h
stdio.h
stdlib.h
stdarg.h
iostream
string.h
Valószínűleg kell majd még ezenfelül egy-két include állomány, bár nem sok, azért, mert fogok egy beépített típust csinálni arra is hogy „fájl”, meg arra is hogy „directory”. Ne kelljen már mindig szopni azzal a mezei programozónak, hogy miként olvassa be egy tartalomjegyzékből valami tömbbe a fájlok vagy könyvtárak nevét... Az nagyon gyakori! Ezekhez kellhet esetleg pár extra headerfájl, de ezek se valami különleges dolgok.
Más függősége nemigen lesz. Persze ennek ára van: ez neked nem fog ám alapból grafikát kezelni, csak ha valaki ír hozzá függvénykönyvtárat, de hogy az nem én leszek az is halálbiztos...
A bináris mérete jelenleg picit kevesebb mint 150 K, most ezt vesd össze kérlek azzal, hogy maga a Bash is kb 800 K egymaga! Mondjuk ha beleteszek még mindenfélét, biztos megnő az enyém mérete is, de mérhetetlenül meg lennék lepve, ha valaha is 500 K fölé menne a binárisom mérete!
És a legtöbb interpreter elég szűkkeblűen bánik a típusokkal. Nálam megvan minden ami a C nyelvben szokásos.
Tudom jól, hogy a fenti példában mi az ami elszörnyesztő: az, hogy a változóim miért ilyen fura nevűek. Nos, nem amiatt, hogy direkt egyénieskedjek! Abszolút nem ez a célom. Nézd meg, még az „if” utasítás is „if” maradt nálam, nem kereszteltem át arra, hogy „ha”, csak azért hogy magyarkodjak vagy akármi!
Szóval, nem egyénieskedésről van itt szó. Tudom, nehéz elhinni, de így van. Hanem, én nem úgy estem ennek neki, hogy elgondoltam valami elvont koncepciót, aztán nekiesek és megcsinálom. És akkor a nyelvem szép lesz meg cuki és aranyos és könnyen tanulható és kinyalja a programozó seggét — közben meg 1024 magos processzorrendszer kell hozzá folyékony hélium hűtéssel, amíg egy „Hello Word” stringet kiír neked egy ciklussal egymás után 10-szer! Tudjuk milyen a Java, a PHP meg a többi. EZÉRT ilyenek.
Én ellenben nem ezt tettem. Abból indultam ki, hogy mi az, ami alapból adott assembly szinten, s erre építkeztem. Szerencsére, elég jó fogalmaim vannak arról a nyelvről (is). Nem vagyok benne profi távolról se, de tudom, kb mikre képes, mik a jellemzői. És azt mondtam, csinálok egy olyan nyelvet, ami a lehető LEGISLEGMAGASABB SZINTŰ, de úgy, hogy interpreter típusú legyen (a hordozhatóság miatt), ne kelljen előfordítani se valami „köztes nyelvre”, mert az is időveszteség, meg plusz tárterület, és a lehető leggyorsabb legyen. Na most mindez behatárol ugyebár némely dolgokat a nyelv szerkezetét illetően. A legkritikusabb, legproblémásabb résznek a változók nevét találtam, sajnos. Nem vagyok idióta, meg tudtam volna csinálni hogy a drága „beszédes” változóneveket is elfogadjon, de akkor a változónév minden előfordulásakor végig kéne bogarásznia egy listát, hogy meglelje a címét. Az ilyesmi miatt döglassúak az interpreterek általában. Na de nekem a gyorsaság a célom! Akkor is, ha emiatt a progranyozó munkája nehezebb lesz valamicskét. A kódot elvégre csak egyszer kell megírni, de futni már rengetegszer fog.
Különben meg csak amiatt ilyen fura a számodra, mert nem ismered a szintaxist. Mi a fene olyan nehezen megjegyezhető ebben például, hogy:
#c@X
# = típusjelölő karakter
c = unsigned char típus (Más karakterek más típusokat jelölnek a # után, a #i például unsigned short int).
@ = változóról van szó
X = a változónak az a neve, hogy "X".
A #c azonban nemcsak változó előtt állhat, hanem egész aritmetikai kifejezést is castolhat.
Szerintem ez abszolút nem nehéz. Az meg külön nyalánkság, hogy a fenti példában az "X" helyén, ami ugye nálam a változó neve ott, azon a helyen szintén állhat egy TETSZŐLEGES ARITMETIKAI KIFEJEZÉS(!!!), amiben persze lehetnek további más változók is! Mindez akárhány mélységi szinten egymásba ágyazva!
Gondold el ember, ez mekkora előny!
Előre szólok, most a következő amit megoldok a string típus beletétele lesz, s már most tudom, nálam a stringeknek lesz olyan lehetőségük is (egy művelet velük) hogy a string VÉGREHAJTÁSA, azaz ha a string egy mau programnyelven megírt kódsort tartalmaz, azt egyszerűen végre lehet vele hajtatni! Még csak nehéz se lesz hogy ezt megoldjam. Teli van már most is ínycsiklandozó „geek” dolgokkal a nyelvem, s még mi minden jár a fejemben! Fogalmam sincs róla, ezek miért nincsenek benne az eddigi interpreteres nyelvekben, amikor KÉZENFEKVŐEK, de úgy tűnik egyszer valaki csinált egyféle nyelvet, aztán mindenki más leragadt annál a stílusnál, ami már megvan az gúzsbaköti a fantáziájukat! De leginkább azt nem értem, akkor mi a jó nyavalyáért olyan hatalmas mammutméretű szarok ezek a vackok, mitől akkora a kódbázisuk, ha alig van bennük valami!
Szóval, én nem veszek bele a nyelvembe olyasmiket, amiket a gép csak nyögvenyelősen tud végrehajtani, bonyolultan, s emiatt LASSAN, ellenben amire képes, ott aztán a végletekig kihasználom a lehetőségeit!
Ezt az egészet úgy a legjobb elképzelned, mintha egy virtuális számítógéped lenne. A mau nyelven megírt fájl, a forráskód, az e virtuális gép RAM-jának az a része, ami a végrehajtandó bináris kódot tartalmazza, természetesen e virtuális gép gépi kódjában megírva. Van ezen kívül persze e virtuális gépnek is adatmemória-szegmense, de az most nem lényeges, az hasonlóan kezeltetik mint megszoktuk. Ellenben e kódszegmensben ő ugyanúgy dolgozik mint minden „normális” gép: bájtonként halad előre az utasítások értelmezésében, egy utasítás majdnem mindig 1 bájtos, nagyon ritkán 2 bájtos. Persze vannak esetek amikor ugróutasítást hajt végre. Na most én azt akartam, hogy megalkotok egy olyan virtuális gépi nyelvet, ami szövegszerkesztővel szerkeszthető, ami gyors, mert alkalmas efféle végrehajtásra, ugyanakkor ezen feltételek betartása mellett a lehető legmagasabb szintű. Szerintem eddig remek munkát végeztem.
Na ha e postot elküldtem, megyek és fejlesztem tovább.