( bucko | 2020. 11. 16., h – 15:49 )

Így van ez a kis processzoroknál. ;)

Még az 512B memóriájú PIC is több esetben 24 bites pointert használ. Azaz nem kell használni, de a U:H:L bájtok közül törlöm az U-t a program elején. Bár a reset is törli, de biztos, ami biztos.

Ha belegondolsz, ez éppen a hordozhatóságot támogatja. Amint nagy memóriával rendelkező vagy külső memóriával ellátható típusra hordozod a programot, rögtön nem kell semmit tenni. (Es nem biztos, hogy csak a C-ben lehet ilyet tenni.)

Ha a fordító támogat egy processzor típust, akkor van hozzá header, ami leírja mi hol mennyi van. Ezt kell tanulmányoznod és az ott található szimbólumokkal kell dolgoznod. Bár a szitaxis miatt külön asm és C headerek lehetnek, de lényegében ugyanazt írják le.

A C-ben nincsen org, a Microchip az absolute direktívát használja helyette. Ezzel lehet megmagyarázni, hogy a cucc ugyan data, de pont hol kell elhelyezni. A header biztosan tartalmaz olyan címkét, amivel az alsó ramra hivatkozhatsz. Erre is igaz, hogy

Elvileg, ha maradsz a compiler által követelt konvencióknál, akkor egy mozdulattal megteheted.

...a nagyobb processzorra váltást.

Itt megint a C aggyal van baj. A régi Intel AS fordítóhoz tartozott linker és lokátor(!). A lefordított programmodulokat "tetszőleges helyre" lehetett linkelni, de később tetszőleges helyre (re)lokálni. Így pl. a tíz programmodulból lefordíthattad az elkészült hármat, összelinkelhetted, és a debugger automatikusan lokálta az ő munkaterületére. Aztán tesztelhetted RAM-ban egy másik helyen, majd EPROMBA égethetted megint másik címtartományokba lokálva. És ez eddig abszolút kód. Aztán jött a C, az obj és ezek a fícsörök köddé váltak... Na, ezért írok abszolút kódban mindent és kézzel "lokálok". Néhány termék után kialakul, hogy az egyes modulokat hol érdemes elhelyezni.

A multitask és a stack beszélgetnek. :-D

Azért látom, nem vagy kezdő a témában. Hasonlót csináltam nagyon-nagyon piciben a 80286 protected hívását utánozva, 8085-ön. Külső memóriával egyszerűbb volt. Készítettem egy contex regisztert, ami belülről írható-olvasható volt, kifelé pedig kicsit beavatkozot a címzésbe. A változók minden taskban ugyanott voltak, de a taskhoz rendelt memóriába íródtak. (Ez már szinte protected mód. ;)) Persze volt egy supervisor is, aminek teljesen máshol volt mindene. Na, ez tudott kezelni 4 kötőgépet (motorindítás, fékezés, sorszámlálás, lakat pozíció), egy kijelzőt és 4 terminált. A terminál 2 led és 2 nyomógombból állt. ;) Ehhez volt 384 bájt RAM, de egyáltalán nem volt kihasználva. Egy nehéz dolog volt benne, a több gépen többszörös hiba esetén a kijelző megszerzéséhez írt prioritásos handshaking. ;)

A "multitasking" az inkább operációs rendszerek alatt értelmezhető. Bár pont az előbb írtam le egy hasonlót, de az csak "ha egy szerkezetet tudok kezelni, akkor négyet is" - némi hardver támogatással.

Ha elmeséled miért vagy annyira a csúnya interruptoktól beszarva ;), akkor szívesen segítek a megértésben. A processzorodban van valami prioritás vezérlő (rutinból: reméljük műküdik), csak azt kell a legbarátibb módba kapcsolni. Aztán az interrupt ugyanolyan, mint a többi program, de legalább csak néha fut. :-D Mivel kifejezetten eseményvezérelt rendszereket írok, nálam az interrupton kívül futó dolgok mennek csodaszámba. Ha ezen túljutsz, más értelme lesz a "kéne egy kis multitasking" gondolatnak is.

A stack...amit én használok, abban 31 szintű hardver stack van. A "magasszintű nyelvek" szoftverből emulálják a függvényhívási konvencióhoz szükséges stacket. Szerintem a 6 mélységet még soha nem értem el, pedig van 2 interrupt level, és egyáltalán nem spagettikódot írok. ;)