Namost a megszakítás azt csinálná, hogy az adott (eppen megszakított) "szál" nyilvántartott memória struktúrájába lementené a regisztertartalmakat, mindent, árnyékot, stack -et, IP -t, és venne egy másik szál struktúrát amiből meg feltöltené a regisztereket, szintén mindet. Természetesen az SP/IP visszatoltéshez valami olyan trükköt alkalmazva, hogy a RETI kiadása előtt valami területre (pld. nulláslap első 100H -ján keresni valami használható helyet) lementene egy kis programocskát, ami feltölti SP -t és ráugrik az új IP -re. Aztán módosítaná a stack -en a megszakítás visszatérési címét ennek a kis programocskának a címére, és a RETI akkor oda "térne vissza", nem oda ahol megszakította az előző szálat, a kis programocskánk meg ugye beleugrana az új (nyilván korábban már megszakított) szálunkba.
Amit akarsz azt CPU schedulernek hivjak, es altalaban ugye multitask OS-ek fontos resze, es pont igy mukodik
Ott persze vannak olyan finomsagok, hogy ha egy process "sleep" allapotban van (pl I/O eredmenyere var, vagy a program azt mondja hogy sleep(10) ezert 10 sec-re nem kell futnia, stb) vagy nagyobb prioritast kert, akkor nem feltetlen rr (round-robin) sorrendben, linearisan kapja a cpu time slice-okat.
Amugy a primo emulatoromban is van hasonlo mar
ha erzekeli hogy megnyomod az F1-et (ez a verzio meg nincs release-elve ...) akkor lementi a regisztereket (az egeszet Int handlerben nezi csinalja) es nem oda ter vissza, igy megkapja az ember a menut, ahol mar CPU allapotat, memoriat is lehet vizsgalni. Es persze vissza lehet terni az emulacio futtatasahoz is. Vegulis ezt is fel lehet ugy fogni, hogy ket program fut parhuzamosan ugymond, csak eppen a valtogatas koztuk user triggerelt es nem automatice
A gondom csak az vele, hogy neha beall az egesz gep tole, de gyanitom hogy en rontottam el valamit valahol.
Így akkor tehát párhuzamosan futnának a "szálak" olyan időosztással amit a megszakítással megadunk.
Ja, std time sharing system, amit anno az uts (unix time sharing) kepeben talaltak fel, es megszulettek a multitask OS-ek
A kérdésem az lenne, hogy vajon milyen frekvenciával lennénk képesek ezt a szál váltogatást csinálni, hogy azért pár órajelciklus még a futó szálnak is maradjon, mielőtt jön az új szálváltó megszakítás ? Tehát egy olyan kód, ami összes regisztert lepakolja memóriába, aztan az összeset visszatolti egy másik memóriáról, és kiad még 1-2 utasítást, megfejelve mindezt a megszakítások esetleges késleltetéséhez (ha van a megszakításkezelésnek valami büntetése), vajon milyen frekivel lehetne ezt pörgetni ? Teszem azt 1KHz -es megszakításnál, mikor ugye egy szál az egy ezredmásodpercig futna, akkor az egy ezredmásodpercnek kb. hány % -a mehetne el fentebb cizellált szál váltó kód futtatására és mennyi maradna a tényleges szál futtatásra ?
Az ezredmasodperccel az a gond, hogy gondold el, van overhead-je a context switchingnek (ha mar multitask OS szeru dolog, hasznaljuk a szakkifejezeseket onnan). Ha tul gyakran van, akkor egyre jelentosebb CPU idot visz el ez a muvelet, viszont annal folyamatosabbnak tunik az egyes szalak futasa. Linux eseten is csak std 100Hz volt anno amugy, most epp nem tudom
meg az ujabb kernelekben mar dynamic tick stb is van (valtozik hogy mikor jon a kov scheduling interrupt attol fuggoen hogy a run queue-ban varakozo processekrol mit tud a kernel - azert is fontos ez mert ha tobb ideig nem kell egy process-nek sem a CPU akkor tovabb lehet halt-ba tenni vagy mas energiatakarekos modba lokni addig a cpu-t, ez pl notebook eseten nagyon durva kulonbsegeket okoz, hogy mennyire jo ebben az adott OS!). Imho egy Z80 eseten se erdemes 100Hz fole menni, felteve ha altalanos OS-t irsz ugymond, nyilvan ha valami specko celra kell, adott korulmenyek kozott, akkor lehet tobb, de a switching overhead-jere szamitani kell!