Ji°φ Peterka

Mechanismus p°eruÜenφ je v poΦφtaΦφch vyu₧φvßn k vφce r∙zn²m ·Φel∙m - o n∞kter²ch jsme se ji₧ zmφnili ve dvou poslednφch p°φsp∞vcφch tΘto rubriky, kdy jsme se zab²vali podstatou vnit°nφch a vn∞jÜφch p°eruÜenφ. V obou t∞chto p°φpadech p°itom Ülo o takovß p°eruÜenφ, kterß byla spφÜe "vedlejÜφm efektem" jin²ch Φinnostφ. Jestli₧e nap°φklad urΦitΘ vn∞jÜφ p°eruÜenφ signalizuje ukonΦenφ n∞jakΘ vstupn∞/v²stupnφ operace, pak tuto vstupn∞/v²stupnφ operaci musel n∞kdo iniciovat (tj. n∞kter² program resp. proces), a jeho cφlem p°itom nebylo p°eruÜenφ jako takovΘ, ale pouze zajiÜt∞nφ urΦit²ch vstupn∞/v²stupnφch akcφ. Jin² p°φklad: jestli₧e prßv∞ probφhajφcφ instrukce zp∙sobφ v²padek strßnky (oÜet°ovan² vnit°nφm p°eruÜenφm), ned∞lß to proto, aby vyvolala p°eruÜenφ jako takovΘ, ale proto, aby si naΦetla Φi zapsala n∞jakß data do p°φsluÜnΘ strßnky.

Existuje ovÜem i takovß mo₧nost, ₧e prßv∞ probφhajφcφ program vyvolß p°eruÜenφ zcela zßm∞rn∞, a vlastn∞ si tak vynutφ provedenφ urΦitΘho obslu₧nΘho programu. Jakß je ale logika takovΘhoto poΦφnßnφ? K Φemu je to dobrΘ?

Pro odpov∞∩ si musφme nejprve uv∞domit, ₧e ka₧d² program, proces Φi ·loha pracuje v₧dy v urΦitΘm prost°edφ - je obklopen jin²mi programy, procesy Φi ·lohami (ve vφce·lohovΘm prost°edφ), je spouÜt∞n operaΦnφm systΘmem, kter² mu zprost°edkovßvß r∙znΘ slu₧by atd. Obecn∞ se tedy v rßmci jednoho poΦφtaΦe vyskytuje vφce programov²ch entit, kterΘ n∞jak²m zp∙sobem koexistujφ vedle sebe, a musφ mφt k dispozici n∞jak² mechanismus pro vzßjemnou komunikaci. Takovßto pot°eba komunikace je nezbytn∞ nutnß, a to i v jedno·lohovΘm prost°edφ, kde (jedin²) prßv∞ probφhajφcφ program musφ mφt mo₧nost komunikovat s operaΦnφm systΘmem, aby si od n∞j mohl vy₧ßdat jeho slu₧by - nap°φklad p°id∞lenφ dalÜφ volnΘ pam∞ti, otev°enφ urΦitΘho souboru, Φtenφ dat ze souboru atd. Zastavme se nynφ u toho, jak²m zp∙sobem mohou b²t slu₧by operaΦnφho systΘmu programu, resp. program∙m zp°φstupn∞ny.

Poskytnutφ urΦitΘ slu₧by ve svΘ podstat∞ v₧dy znamenß provedenφ urΦitΘ posloupnosti strojov²ch instrukcφ. Ve vφce·lohovΘm prost°edφ je mo₧nΘ koncipovat operaΦnφ systΘm jako "trvale b∞₧φcφ" ·lohu, kterß svΘ slu₧by poskytuje na zßklad∞ po₧adavk∙, p°edßvan²ch jin²mi ·lohami formou zprßv (tj. jako data, kterß blφ₧e urΦujφ, co a jak je na operaΦnφm zp∙sobu po₧adovßno). Äadatel se p°itom nemusφ sßm starat o to, aby operaΦnφmu systΘmu p°edal °φzenφ (a tento mohl po₧adovanΘ akce skuteΦn∞ vykonat), nebo¥ toto je ve vφce·lohovΘm prost°edφ zajiÜt∞no automaticky. Pon∞kud jinß situace je ovÜem v jedno·lohovΘm prost°edφ, kde se ₧adatel musφ sßm postarat o to, aby operaΦnφ systΘm "pustil ke slovu". Zde proto b²vajφ jednotlivΘ slu₧by operaΦnφho systΘmu koncipovßny jako podprogramy (kterΘ jsou p°φmou souΦßstφ operaΦnφho systΘmu), a prßv∞ probφhajφcφ program si pak provedenφ po₧adovanΘ slu₧by zajistφ tak, ₧e p°φsluÜn² podprogram sßm zavolß.

Otßzkou ovÜem je, jak majφ b²t u₧ivatelsk²m program∙m zp°φstupn∞ny vstupnφ body takov²chto podprogram∙, kterΘ jsou souΦßstφ operaΦnφho systΘmu. Tato otßzka mß dva aspekty: prvnφ je ten, ₧e p°φsluÜnΘ podprogramy mohou b²t v r∙zn²ch verzφch operaΦnφho systΘmu umφst∞ny jinde - co₧ ale zp∙sobuje nesmφrnΘ komplikace aplikaΦnφm program∙m, kterΘ dost dob°e nemohou anticipovat zm∞ny, ke kter²m dojde v nov²ch verzφch operaΦnφho systΘmu. Jednoduch²m °eÜenφm je ovÜem nep°φm² p°φstup k p°φsluÜn²m podprogram∙m: na p°edem urΦenΘm mφst∞ - stejnΘm pro vÜechny verze - budou ulo₧eny ukazatele na tyto podprogramy (tj. adresy jejich vstupnφch bod∙). Vlastnφ podprogramy pak mohou b²t umφst∞ny v podstat∞ kdekoli, proto₧e ₧adatelΘ o provedenφ p°φsluÜn²ch slu₧eb k nim budou p°istupovat zßsadn∞ jen p°es tyto ukazatele.

Druh²m aspektem je mo₧nost ochrany operaΦnφho systΘmu p°ed nevhodn²m chovßnφm prßv∞ probφhajφcφho programu. Kdyby toti₧ tento program mohl volat kter²koli podprogram v rßmci operaΦnφho systΘmu, mohl by velmi snadno p°ekonat jak²koli zabezpeΦovacφ mechanismus - pouh²m volßnφm tΘ Φßsti operaΦnφho systΘmu, kterß jej odblokuje, resp. kterß provede takovΘ akce, na kterΘ by program jinak nem∞l prßvo. Stejn∞ tak nebezpeΦnΘ m∙₧e b²t i necht∞nΘ "zabloud∞nφ" programu do operaΦnφho systΘmu.

OperaΦnφ systΘm by tedy nem∞l "pouÜt∞t" prßv∞ probφhajφcφ program kamkoli, ale jen na p°esn∞ definovanß mφsta (tj. zp°φstupnit mu jen n∞kterΘ svΘ podprogramy), kde pak m∙₧e kontrolovat oprßvn∞nost a korektnost vznßÜen²ch po₧adavk∙. K tomu je ovÜem zapot°ebφ vhodn² mechanismus, kter² ₧adateli umo₧nφ volat jen takovΘ programy, kterΘ mu operaΦnφ systΘm sßm nabφdne.

Jednφm z mechanism∙, kter² je schopn² toto zajistit, je prßv∞ mechanismus p°eruÜenφ. Jak ji₧ vφme, v²sledn²m efektem p°ijetφ ₧ßdosti o p°eruÜenφ je provedenφ obslu₧nΘho programu. ProΦ tedy nekoncipovat podprogramy operaΦnφho systΘmu, poskytujφcφ jednotlivΘ slu₧by, jako obslu₧nΘ programy, a nabφzet zajiÜt∞nφ p°φsluÜn²ch slu₧eb formou p°eruÜenφ?

K tomu jsou zapot°ebφ jeÜt∞ dv∞ v∞ci: aby mohly b²t tφmto zp∙sobem poskytovßny r∙znΘ slu₧by, musφ b²t ₧ßdosti o p°eruÜenφ vhodn²m zp∙sobem diversifikovßny - musφ existovat r∙znΘ druhy, typy Φi t°φdy p°eruÜenφ, a ka₧dΘ bude odpovφdat jeden obslu₧n² program, poskytujφcφ urΦitou konkrΘtnφ slu₧bu.

DalÜφm nezbytn²m p°edpokladem je to, aby prßv∞ probφhajφcφ program mohl zcela zßm∞rn∞ vyvolat p°eruÜenφ urΦitΘho typu (Φφsla, t°φdy), a tφm si vlastn∞ vy₧ßdat provedenφ p°φsluÜnΘ slu₧by operaΦnφho systΘmu. Za tφmto ·Φelem musφ b²t procesory vybaveny strojov²mi instrukcemi pro tzv. programovΘ p°eruÜenφ (software interrupt). Operandem t∞chto instrukcφ je pak ·daj, kter² urΦuje konkrΘtnφ typ (druh, t°φdu) p°eruÜenφ, a tφm zprost°edkovan∞ i po₧adovanou slu₧bu.

Instrukce programovΘho p°eruÜenφ je tedy strojovß instrukce, jejφm₧ jedin²m efektem je zßm∞rnΘ vyvolßnφ urΦitΘho p°eruÜenφ. To b²vß samoz°ejm∞ nemaskovatelnΘ.

╚φm se ale instrukce programovΘho p°eruÜenφ liÜφ od b∞₧nΘ instrukce volßnφ podprogramu, kdy₧ ve svΘ podstat∞ takΘ pouze vyvolß provedenφ urΦitΘho podprogramu (obslu₧nΘho programu)? Hlavnφ rozdφl je v tom, ₧e jde vesm∞s o volßnφ nep°φmΘ - volajφcφ zde nemusφ znßt konkrΘtnφ adresu volanΘho podprogramu. Specifikuje pouze jeho nep°φmou adresu, tedy vlastn∞ jen mφsto, na kterΘm je ulo₧en ukazatel na tento podprogram (co₧ v tomto konkrΘtnφm p°φpad∞ urΦuje typem, Φφslem resp. t°φdou p°eruÜenφ). Je pak na operaΦnφm systΘmu, aby konkrΘtnφ ukazatel na toto mφsto ulo₧il, a tφm vlastn∞ sßm rozhodl o tom, kam volajφcφho "pustφ".