KEZDJÜK A RIZSÁVAL
Igen, tudom, hogy van egy teljesen ugyanilyen leírás a hivatalos fórumon, és azt is, hogy ugyanazt fogom gyakorlatilag elmondani kétszer. Viszont fontosnak érzem, hogy azt az alapot kicsit felturbózzam, és megérthetõvé tegyem azok számára is, akik esetleg nem értik elsõre, hogy mi az a LIFO, heap, stack, és a többi. Épp ezért, és az emészthetõség miatt nem állt szándékomban a formális szaknyelv használata.
Ez után pedig térjünk rá, hogy ez a cikk lényegében kinek jó: akit érdekel. Ettõl a módod gyorsabb nem lesz, kevesebb bug biztos nem lesz benne, nem is lesz stabilabb, tehát tényleg csak azoknak ajánlom, akiket érdekel, hogy valójában hogy is fut le a kódjuk, amit írnak.
AMX
Mint ahogy az a deAMX topicban is elhangzott, az AMX rövidítés jelentése Abstract Machine Executor, vagyis absztrakt gép végrehajtó, értve ez alatt azt, hogy ez az a kód, amivel az absztrakt gép végrehajtja az utasításokat.
AZ ABSZTRAKT GÉPEK
Mi is egy absztrakt gép? Mint azt bizonyára mindenki tudja, a legfontosabb elméleti gép, automata az ún. Turing-gép. Gyakorlatilag egy olyan automata, amely végtelen sok memóriával rendelkezik. De mi is egy automata?
Elõször is szögezzük le, hogy a Turing-gép nem létezik, csak egy elméleti modell. Ezért használunk rá nagyon egyszerû, leíró nyelvezetet. A Turing-gép egy olyan gép, amelyhez egy végtelen hosszú papírszalag tartozik. Minden papírszalagon \"betûk\"/\"szimbólumok\" (ez a hivatalos megfogalmazás) találhatók. Egyszerûség miatt tekintsük ezeket nullának és egynek. A gépbe be van programozva egy adott utasítássorozat, amit végrehajt a szalagon, ezt a logikai vezérlõegységbe programozták be.
Például tegyük fel, hogy a szalagunkra ez van írva: 0[0]11. Az olvasófej a második nullán áll. Tegyük fel, hogy az az utasítássorozat van beprogramozva, hogy
 

1: HA 0 AKKOR 1
2: HA 1 AKKOR 0
3: EGYEL ELÕRE
4: UGRÁS 1-RE

 
A következõ utasítás a szalagon lévõ karaktereket 0100-ra változtatja, és nem áll meg. Amennyiben nem ugranánk vissza egyre a következõ változó értéke már nem lenne módosítva.
MIÉRT ELÕNYÖS AZ AMX?
Az absztrakt gép egy számítógép virtuálisan. Ennek több elõnye van az x86 assemblyvel (tehát a \"tényleges\" natív assemblyvel) szemben:
 

• Több platformon, több architektúrán elfut: a p-kód miatt minden operációs rendszeren és a 8-bitestõl a 64-bites processzorig átportolták.


• A p-kódnak több elõnye is van: a modern operációs rendszerek nem engednek a CODE szegmensbe írni és a DATA szegmenst lefuttatni.


• Sokkal egyszerûbb a programot a saját \"mini-számítógépen\" (sandbox) futtatni: egy natív assemblyben írt program rekurzív utasítása könnyen kifagyaszthatja az alkalmazást, és megrongálhatja a rendszer STACK-jét.

A REGISZTEREK
Az AMX regisztereket használó absztrakt gép. A regiszterek a processzorok elidegeníthetetlen részei a Neumman-elvek óta. Ennek elõnye az, hogy az absztrakt gép utasítása jobban \"rásimul\" a natív kódra, tehát a futásidõ csökken, valamint az utasítások száma csökkenthetõ.
Az AMX egy kétregiszteres struktúra, két számításra alkalmas regiszter található meg: a PRI és az ALT.
Az alábbi kódot:
 

a = bö 2;

 
Az AMX assemblyjében így kaphatjuk meg:
 

load.pri b ;betöltjük a b változót az elsõdleges (PRI) regiszterbe
const.alt 2 ;betöltjük a \"2\" konstanst az alternatív (ALT) regiszterbe
add ;az add utasítás a következõt csinálja: PRI = PRI + ALT
stor.pri a ;az a változóba eltároljuk a PRI értékét

 
A REGISZTEREK LISTÁJA

Regiszter rövidítése	Regiszter teljes neve	Használata
PRI	Primary Register	ALU, logikai és számolási mûveletek
ALT	Alternative register	Másodlagos regiszter a bonyorultabb mûveletekhez
FRM	Stack frame pointer	Egy függvény lefutása elõtti stack állapotot tárolja
CIP	Code instruction pointer	A végrehajtandó utasítás (az AMX-ben szinte mindig a main()-ra mutató pointer)
DAT	DATA pointer	A DATA szegmens kezdetére mutató pointer
COD	CODE pointer	A CODE szegmens kezdete
STP	STACK top	A STACK teteje / legalacsonyabb memóriacíme
STK	STACK index	A STACK jelenlegi helyzete
HEA	HEAP pointer	A HEAP teteje

MEMÓRIAKÉP
Az AMX fájl memóriaképét, vagyis a memóriában elfoglalt helyét mutatja be az alábbi táblázat. A HEAP és a STACK alapvetõen nincs a bináris fájlban, elõállítását az AMX végzi a PREFIX adatok alapján.
Ahhoz, hogy a lenti memóriaképnek megfelelõ bináris kódot kapj, használd a #pragma compress 0 direktívát a scriptedben.

LEGALACSONYABB MEM.-CÍM

PREFIX

CODE

DATA

HEAP ⇊

STACK ⇈

LEGMAGASABB MEM.-CÍM

---

A prefix
A prefix rész a kód legelején terül el, és elsõdleges feladata általános metaadatok, pointerek, és a függvények listáját tárolni. A memóriatérképe a következõ (az X-el jelölt dinamikusan változik az adat mennyiségétõl függõen):
(a teljes táblázat megtalálható a pawn-imp guide-ben, én ezt a verziót Y_Lesstõl szereztem, köszönöm)

MÉRET	Memóriaterület	Leírás
4	Méret	A fájl mérete
2	Ismeretlen
1	Fájl verzió	Az AMX verziója
1	Minimum VM verzió
2	Flagek	A fordítónak fordítás közben megadott paraméterek
2	Defsize
4	COD offset	A CODE szegmens kezdetének helyzete
4	DAT offset	A DATA szegmens kezdetének helyzete
4	HEA offset	A HEAP szegmens kezdetének helyzete
4	STP offset	A STACK szegmens kezdetének helyzete
4	CIP	A main() függvvény memóriacíme (vagy -1)
4	Publikus függvények listájára mutató pointer
4	Natívák listájára mutató pointer
4	Libek listájára mutató pointer
4	Publikus változók listájára mutató pointer
4	Public tagek listájára mutató pointer
4	Names táblára mutató pointer
X	Public lista
X	Native lista
X	Lib lista
X	Pubvar lista
X	Tag lista
X	Name tábla

A listák egy eleme a következõképp épül fel:

MÉRET	Memóriaterület	Leírás
4	Függvény/változó pointer	A függvény kezdetére/vált. helyére mutató pointer
4	Név pointer

A Names tábla a stringeket tartalmazza: ömlesztve, tömörítve ábrázojla.
A stringek NULL-delmitáltak (tehát a minden string végén szereplõ \\0 karakter jelzi a string végét), és tömörítettek. A konstansok (különösen a stringkonstansok) a DAT szegmensben tárolódnak, tehát irrelevánsak jelen esetben.

---

A code szegmens
A TEXT vagy CODE szegmens egy olyan szegmens egy bináris fájlban, vagy a memóriában, amely a futtatható utasításokat tartalmazza. A CODE szegmensnek a memóriában általában csak 1 példányra van szüksége, mivel megosztható. A CODE szegmens szinte mindig csak olvasható, hogy  megakadályozható legyen az, hogy a program véletlen a saját utasításait módosítsa.

---

A data szegmens
A DATA szegmens a program virtuális memóriájának egy része, az egész program számára elérhetõ (ti. globális) változókat tárolja.

---

A heap
A heap, vagy \"halom\" a memória dinamikusan használható része. A \"halom\" igen deskriptív: hiszen gyakorlatilag a halomra akármikor hozzáadhatunk vagy elvehetünk valamit anélkül, hogy az egész összedõljön. Ha egy új dinamikus változót hozunk létre, lényegében a heap-bõl vesszük el a területet.
Mivel a létrehozott változónak lefoglalt memóriaterület sosem ismeretes elõre, a new statement mindig egy pointerrel tér vissza a heapban tárolt pozícióval.
A PAWN nyelv nem használ dinamikus változókat, minden változót vagy a DATA (glob), vagy a STACK (lok) szegmensek tárolnak, ezért például a memory leak-ek nem lehetségesek. Azért ide megemlítem, ha valakinek van kedve a memory leakekhez, hogy Y_Less malloc függvénykönyvtárával lehetõséged van \"dinamikus\" memóriát kiosztani (azért idézõjelbe, mert ez sem igazi dinamikus memória, és ez sem a heapben van, csak egyfajta workaround).

---

A stack
A STACK, hivatalos magyar nevén \"verem\", deskriptívabb nevén \"rakás\" egy memóriakezelési szerkezet. Mielõtt jobban megvizsgáljuk, nézzük meg az alábbi példát:
Tegyük fel, hogy van egy rakás téglád egymáson. Mivel a téglák nehezek és rakásban vannak (tehát mindegyik tégla a másik tetején), ezért lényegében három dolgot tehetsz a téglákkal anélkül, hogy összedõljenek:
 

• Ránézel a legfelsõ téglára


• Leveszed a legfelsõ téglát


• Felraksz egy újabb téglát

A stack egy olyan memóriakezelési struktúra, ami változókat tárol, hasonlóan a tömbökhöz. Viszont míg a tömbökben tetszés szerinti elemet elérhetsz, addig a stack ennél limitáltabb. Lényegében a fenti három dolgot teheted meg a stackkel:
 

• Megnézed, mi a felsõ érték, vagy top


• Leveszed a legfelsõ értéket, vagy pop


• Felraksz egy újabb értéket, vagy push
  

Ahogy a téglás hasonlat is mondja: ha valaki egy téglát rárak a rakásra, akárki, aki levesz egy téglát a legfelsõt fogja levenni. Ez a LIFO-elv: last in-first out. A legelsõ felrakott elem lesz a legelsõ, amit levesznek.
Ez, bár szép analógia, lehetne egy jobbat is létrehozni. Vegyünk egy adott számú postaládát: mindegyik egymás fölött, mindegyik csak egy dolgot tarthat magában, mindegyik üresként kezdi, és persze mindegyik az alatta lévõvel össze van ragasztva, így a számuk nem változik. A kérdés: ha a postaládák száma nem változtatható, hogyan kapunk egy stacket? Jelöljük meg egy matricával a legmagasabban lévõ üres postaládát. Minden a matrica alatt lévõ postaláda a stack tagja, minden a matrica fölött lévõ postaláda nem a stack tagja.
Ez szinte azonos azzal, hogy mûködik a stack. A stack egy elõre meghatározott mennyiségû memória: a postaládák memóriacímek, és a levelek a memóriacím alatt lévõ adatok. A \"matrica\" a fentebb említett STK regiszter: Stack Index/Stack Pointer, ami mindig a legnagyobb elérhetõ stack címre mutat. Az egyetlen különbség a postaládás hasonlat és a valós stack közt az, hogy ha az adatot el akarjuk tüntetni, nem kell \"kiüríteni\" a postaládát: elég a matricát egyel lejjebb helyezni és az a memóriarész onnantól nem a stack tagja, amíg a következõ memóriarész felül nem írja.
Miket rakunk a stackbe? Változókat, paramétereket, és függvényhívásokat.
Mivel a globális változók a DATA szegmensbe kerülnek, ezért nekünk lényegében csak azzal kell foglalkoznunk, mi történik a lokális változókkal: tehát a függvényeken belül meghívottakkal.
Példaképp tekintsük meg az alábbi kódot:
 

main() { new a=4; foo(a,2); }
foo(a,b) { }

 
Ez, a nem mûködõ, viszont példaként tökéletesen használható kódrészlet tökéletes példa a stack bemutatására. Mikoris a main() függvény meghívja a foo függvényt, az alábbi játszódik le (ezt szaknyelven a Standard Entry Sequence-nek  hívjuk):
Az egyszerûség kedvéért a main()-t fogjuk hívni a meghívó függvvénynek míg a foo()-t a meghívott függvvénynek.
 

• A main() ráhelyezi a foo() függvény visszatérési pointerét, vagyis azt, hogy a függvény lefutása után a foo() függvény a main()-en belül hova ugorjon vissza.


• Ezután a main() függvény betölti foo() függvény paramétereit a stackbe fordított irányban (ez az ún. C-declaration order vagy cdecl).


• Ezután következik a main() függvény stack frame pointerének helyzete, szintén rákerül a stackre.


• A fenti adat memóriacíme tárolódik el a Stack Frame Pointerben (FRM regiszter). A pointernek több célja is van: egy részrõl meghatározza, hol kezdõdik az a stack szegmens, ahová a függvényünk (foo()) a helyi változóit fogja tárolni.
  Más részrõl be kell lássuk, hogy az STK (a stack tetejére / legalacsonyabb memóriacímére mutató pointer) nem megbízhatóan adja vissza a változók helyét, hiszen új változók felvétele esetén a stack is feljebb kerül az STK-val együtt. Ez a FRM elsõdleges használati területe: nevezetesen, hogy a függvényekben használt lokális változók létrehozásához a pontatlan STK helyett a függvény lefutása során kötött FRM-t használjuk.
  Mivel a stack memóriacímei csökkennek (lásd a memóriaképet), egy lokális változó (ami a mostani pointer fölött fog lenni) memóriacíme mindig a pointerhez képest negatív, míg a paraméterek értéke mindig pozitív lesz.
  Harmadrészrõl az FRM alatt lévõ memóriacím (tehát a main() függvény ugyanilyen framejére mutató pointer) megadni azt a területet, ahova a függvény lefutásakor vissza kell léptetni a STK-t (érvénytelenítve ezzel az összes lokális változót).


• Ezután természetesen a függvény lefut, és minden lokális változó rákerül a stackre.

Minden stackre helyezett elem esetén természetesen frissítõdik a STK regiszter helye (ami a stack legfelsõ elemét mutatja).
Ha a függvény megáll, lefut a fenti ellentéte, a Standard Exit Sequence
 

• A STK (stack tetejére / legalacsonyabb memóriacímére mutató pointer) értéke frissül a FRM értékére, megszûntetve ezzel a lokális változók elérésnek lehetõségét.


• A FRM a mostani helyzete alatt található értékére frissül (ami pont a meghívó függvény ugyanolyan FRM értéke).


• A main() függvény visszatérési pointerét leszedi a stackrõl és odaugrik, és folytatódik a kód végrehajtása.

Zárásnak még annyit: hogy azért is futnak a több-threades programok gyorsabban, mert mindegyiknek külön stackje van.

---

A heap és a stack, stack overflow
Lehetõség van arra, hogy a stack számára elõre lefoglalt memóriát túllépjük, és beleírjunk a heap-be: ez általában nagy mennyiségû változó esetén következik be, ezt nevezzük stack overflownak.
Ez azért lehetséges, mert a heap és a stack ugyanazt a memóriaterületet kapja, de ellentétes irányban kezdõdnek: a heap egyre növekvõ, míg a stack egyre csökkenõ memóriacímeket kap.
A stack overflow tényérõl a fordító tájékoztatást ad: mégpedig kiírja, hogy az egyes szegmensek mennyi bájtot foglalnak el, és hogy a HEAP/STACK szegmensnek mekkora a maximális mérete, és mekkora az a méret, amit igényelne ahhoz, hogy minden változó elférjen benne. Ez azért lehetséges, mivel a stack mérete a fordítás során már ismert. Jogosan felmerülhet a kérdés, hogy akkor miért nem kap az AMX automatikusan több memóriát a programhoz: ez a mennyiség limitált és alapjában véve nem túl nagy, tehát megeshet, hogy egy normálisabb módhoz is növelni kell. Ezt a #pragma dynamic direktívával lehet megtenni.

---

(és ennyi, frissítések várhatóak)

Azon gondolkdotam, megérné-e csinálni egy központi statrendszert különbözõ típusú szerverekhez. Ez a következõképp zajlana: lenne egy központi web ahova be kéne regisztrálni, mint egy szeró UCPje. Lenne felhasználóneved, jelszavad. Bizonyos szerverek jelentkezhetnének a rendszerbe, akik kapnának egy API ID-t, és egy filterscriptet. Innentõl ha olyan szerveren, ahol ilyen rendszer van beépítve, olyan játékos játszik, akinek a rendszerre van accja, a statjait automatikusan követné és frissítené. A banokat is tárolná és az egész hálózatra érvényesítené, stb.
Persze ebben erõsen bent van az exploit lehetõsége, ezért minden szerver gondosan meg lenne válogatva, és külsõ kapcsolat le lenne tiltva az egyéb szervereknek. A statok esetén a szerverek súlyozva lennének, valamint a tulajok maguk dönthetik el, hogy a ban listát használják-e az õ szerverükön, valamint minden funkciót a szerverek egyesével beállíthatnának, és ezek egy listán látszódnának is.
A kérdés az lenne, hogy szerintetek egy ilyen rendszert érdemes lenne-e megscriptelni, és milyen mûfajon belül lenne értelme?

Nem vagyok a bemutatkozások híve, nem is nagyon tudok mit magamról mondani, de mivel sok ember írt ilyet, és még nekem nem volt, ezért most megírom.
A nevem titok. Veszprém megyében lakom de életvitelszerûen Székesfehérváron élek. A személyes életemet nem szeretném itt megosztani, mert az nem egy internetes fórum témája, de: a jobb szememre születésem óta súlyos tompalátó vagyok, ez abban realizálódik, hogy 20 centinél távolabb egyáltalán nem látok; azon kívül, hogy nem tudok 3D filmeket nézni, eddig nem akadályozott semmiben (a 3d film amúgy is basszná a szemem, ahogy az alacsony FPS-û játékok is).
SAMP-ozni már 0.1 óta elkezdtem, de rendszeresen a 0.2x megjelenése óta játszom. Szinte az egész pályafutásom alatt csak RP szervereken játszottam: a Fay-on kezdtem, ott egy ideig az új modjukat is írtam, aztán LT, aztán Paradise, aztán Core, aztán Foothills, meg pár saját projekt (w0llfram). Az én véleményem a SAMP RP-vel kapcsolatban az, hogy az egyes asztali RPG elemeket (olyanokat, mint karakterlap vagy élettörténet) csak módjával lenne szabad egy normális modba berakni, a játékosoknak kéne tudniuk eljátszani a szerepüket mindenféle szabályzat nélkül. Ennek látszólag ellentmondhat a tény, hogy én magam is írtam egy asztali RP-jellegû modot, de az nem titkoltan arra szolgált, hogy azok, akik ezt kívánják, megkaphatják.
A SAMP fórumos karrieremet valamikor 2010 környékén kezdtem. 2013 januárjában kaptam elõször lokális moderátor rangot a Szerverek alfórumba (miután megpályáztam azt), majd Csabi kinevezett lokális moderátornak a Beszélgetések alfórumba. 2013 július elsejétõl pedig mint Globális Moderátor vagyok jelen.
Hobbijaim:
 

• elsõdleges hobbim a programozás, a végsõ célom hogy x86 Assemblyben egy középfokon tudjak programozni; kicsit ehhez köthetõ a különbözõ játékok hackelése (fõleg NES játékok), valamint különbözõ játékok modolása. PAWN-ban elég jól tudok már programozni, írtam is pár leírást (például a SAMP fórum elsõ teljes PAWN tutorialját), illetve tervezek is írni a PAWN mélyebb részeirõl


• az angol nyelv, az angol és amerikai irodalom, valamint az amerikai történelem és kultúra. Sikerült 2013 áprilisában letennem a CAE (Cambridge English: Advanced) nyelvvizsgát, A jeggyel (CEFR C2)
  Kedvenc angol íróim közé tartoznak George Orwell (különösen az 1984), Herman Melville és P.G. Wodehouse. Aki jobban tud angolul és fogékony a klasszikus irodalomra, annak melegen ajánlom Homérosz, Vergilius, és Platón (különösen a Szókratész védõbeszéde) próza verzióit (a verses verziókban a magyar aláz) prózában, sokkal jobban olvashatók angolul (szerintem)


• repülés, IVAOn, VATSIMen irányítás


• írás (mint magyarul, mint angolul)


• félrefordítások gyûjtése


• különbözõ linux rendszerek karbantartása (a régi általánosba még mindig sokszor bejárok ezügyben)


• diákpolitika (iskolai DÖK)

Kedvenc játékaim: a kedvenc sorozatom messze a GTA sorozat, ezen felül bizonyos régifajta szöveges kalandjátékok/RPG-k (pl. MUD), a Quantic Dreams játékai (Heavy Rain, Indigo Prophecy), Battlefield sorozat.
Van már egy elég hosszan elhúzódó projektem, hogy elkezdek egy szövegalapú RPG-szerûséget írni, de még nem szántam rá magam, hogy elkezdjem.
Mostanában a Malibun játszok, az mellett pedig LSRP-n ismét jelentkeztem rendõrségre (olyan március környékén ki**sztak inaktivítás miatt).
Kedvenc zenéim: sok van, általában fõleg rock-metal vonalon mozgok, de hallgatok countryt és raget is (fõleg Joplint). Nem vetek meg semmilyen fajta zenét sem, ha tetszik, hallgatom.
Ide kéne írjak listát, hogy kiket ismerek, kikkel vagyok jóba, és a többi, de inkább kihagyom, aki tudja, az úgyis tudja.

Üdv!
Már elképesztõen hosszú ideje tervezgetem egy saját játék készítését, de mivel a grafikai munkálatokhoz nekem sem idõm, sem energiám, sem türelmem nincsen, ezért egy ideig halogattam, és fõleg GTA:SA-ban alkottam sok kicsi, meg nem jelenõ single-jellegû projektet. Aztán a MUD 1-rõl, az egyik legjobb RPG-rõl jutott eszembe, hogy ezt meg lehet csinálni grafika nélkül is. Ezt is halogattam egy csomó ideig, aztán egy személyes esemény közeledte miatt úgy gondoltam, itt az ideje ebbe is belevágni. A múlt héten megbarátkoztam az ADRIFT nevû IF (interaktív fikció)-készítõ programmal, és nekiállok a játéknak, vagy inkább egy Heavy Rain-szerû interaktív könyvnek (nem összetévesztendõ a \"lapozós\" RPG-vel, de hasonló, csak itt tényleg interakcióba léphetsz a dolgokkal, nem csak két lehetõség közül választhatsz). A genre egyik alapvetõ alapelve, hogy nem halhatsz meg, ezért a játéknak gyakorlatilag nincsen \"jó\" és \"rossz\", csak többféle befejezése.
Itt egy példa az interakció mélységére, és ez még semmi: ebben a szobában minden egyes tárgyat megvizsgálhatsz, megnézheted az ablakokat, kinyithatod és becsukhatod õket, a két órával az idõt is megtekintheted, a jegyzettömböt és a tollat magaddal viheted, berakhatod a szekrénybe, az ágy alá, a gardróbból kivett ruhákat felveheted, és a többi. És természetesen minden ilyen interakciót kb. 2 perc beállítani a szoftverben, a legtöbb idõt a szöveg megfogalmazása veszi el. Ezért ilyen f***a az IF interaktív könyvekre.
Mint ahogyan ezt írtam már korábban, ez elsõsorban egy személyes projekt, tehát nagy valószínûséggel nem fog megjelenni a közeljövõben, maximum egy demó verzió (és amúgy is angolul van az egész), de azért kíváncsi vagyok, hogy mit gondoltok az ilyen jellegû játékokról.