Zastosowanie stosu i obsługa przerwań w asemblerze - jak to działa?

Witam!!
Dwa banalne pytanka. Gdyz na wszystkie strony szukam odpowiedzi.
1. Stos-wiem,ze sluzy do odkladania danych podczas obslugi przerwania,ze jest umieszczany tam aktualny numer licznika rozkazow a czy nie mozna po prostu odlozyc tych zmiennych do rejestrow roboczych??
2. Obsluga przerwania. Na poczatku kazdego programu podajemy adresy obslugi przerwan ok(rozumiem). Podczas dzialania programu glownego ->zgloszenie przerwania->odkladanie danych na stos->obsluga przerwania. Jak to dokladnie dziala??Co robi dokladnie procek po zgloszeniu przerwania, jak wykorzystuje te dane, ktore na poczatku kazdego programu sa deklarowne??
Wiem,ze te pytanka sa bardzo banalne,ale probuje zglebic asemblera,ale wszedzie pisza tak samo(strony,ksiazki)i nie moge tego pojac...
Prosze o pomoc./smalski

Stos w pamieci ma jedna ogromna zalete... moze byc teoretycznie "nieograniczony" rozmiarami.
Ile mozesz miec takich rejestrow roboczych w pamieci? 1 zestaw? 5 zestawow? 15 zestawow? Jak z nich nie korzystasz to marnuja sie zasoby procka... jak potrzebujesz wrzucic na stos wiecej danych niz mialbys rejestrow to procek moze wysiasc, mimo ze ma jeszcze mnostwo wolnej pamieci i tam moglby wsadzac i wsadzac duzo danych poprzez zdeklarowanie czesci tej pamieci jako stos.
Stos moze osiagnac spore rozmiary gdy uzywasz takich rzeczy jak funkcje rekurencyjne, gdzie funkcja wywoluje sama siebie wielokrotnie. Jezeli nie wiesz co to sa funkcje rekurencyjne to www.google.com i juz wiesz


Samo dzialanie obslugi przerwania wyglada mniejwiecej tak:

a)procek wykonuje program... (uzywa rejestry itd)

b)wywolane zostaje przerwanie, program zostaje przerwany (zatrzymany), dane rejestrow zostaja przepisane na stos

c)Procesor skacze do kodu, ktory jest odpowiedzialny za obsluge tego konkretnego przerwania i zaczyna go wywolywac. Kod ten moze sobie dowolnie zmieniac rejestry w mikroprocesorze i robic w sumie co mu sie podoba

d)kod przerwania wywoluje funkcje ret/return i zglasza prockowi, ze obsluga przerwania zostala zakonczona

e)procek ze stosu laduje wszystkie dane spowrotem do rejestrow (w tym adres licznika instrukcji, zeby kontynuowac wykonanie programu glownego z tego miejsca gdzie zostal on przerwany)

f)program glowny wznawia operacje... dla niego caly proces wywolania przerwania byl niewidoczny.


Na podobnej zasadzie dziala wywolywanie funkcji instrukcja call . Umozliwia to wywolywanie kawalkow kodu odpowiadajacych za jakies czesto wywolywane operacje bez potrzeby wklejania tego kodu, powielania czy jakiegos integrowania go z programem glownym. Obsluge wywolania i powrotu z kodu funkcji robi procesor, a jedynie (w zaleznosci od typu mikroprocesora) uzytkownik musi czasami sam wrzucic rejestry na stos.

Na poczatku kazdego programu umieszcza sie tzw Tablice wektorow przerwan. Procesor ma zaszyte na stale pod jaki adres ma skoczyc gdy otrzyma przerwanie. Gdy otrzyma takowe skacze w odpowiednie miejsce tablicy. Po drodze na stosie zachowuje aktualny adres licznika programu zeby wiedzial w ktore miejsce ma wrocic po wykonaniu instrukcji reti informujacej o zakonczeniu obslugi przerwania. Poniewaz adresy wektorow w tablicy sa rozmieszczone blisko siebie (przewaznie co dwa bajty) to nie zmiesci sie tam zaden rozsadny program.Dlatego umieszcza sie tam kolejny skok do wlasciwej procedury przerwania (stad nazwa tablica wektorow).Gdy masz tylko 1 przerwanie to mozna jego obsluge umiescic w miejscu wektora, nie przeszkodzi to innym przerwaniom (bo ich nie bedzie zyskujesz pare cykli bo nie potrzebna jest instrukcja skoku) Nie jest to jednak zalecane. Gdy przerwanie dobiegnie do konca i napotka rozkaz reti wtedy ze stosu odzyskujesz licznik rozkazow (adres w programie) ze stosu i skacze do tego miejsca. Jesli w procedurze obslugujacej przerwanie nie namieszales i nie pozmieniales rejestrow wykorzystywanych w glownej czesci programu to po powrocie z przerwania program glowny dziala jak gdyby nigdy nic. Jezeli z jakis powodow musisz korzystac z tych samych zasobow (rejestrow) w przerwaniu co i w programie glownym stos moze sluzyc do tymczasowego przechowywania zawartosci tych rejestrow. Nalezy tylko pamietac o odpowiedniej kolejnosci odkladania i zdejmowania danych ze stosu, gdyz mozesz je poieszac a najgrozniejsze bedzie pomieszanie odlozonego automatycznie licznika programu z Twoja dana. Program po powrocie z przerwania nie wroci do miejsca w ktorym znajdowal sie przed przerwaniem.
Obsluga stosu to nie tylko asembler. Poniewaz odkladanie (i odzyskiwanie) licznika programu odbywa sie automatycznie to ta kwestia dotyczy kazdego jezyka programowania. Jezyki wyzszego rzedu przewaznie jednak same sie troszcza o obsluge stosu zwiazana z wykonywanym programem. Stos pelni bardzo wazna role w procesorach i w niektorych np.C51 sluzy jeszcze do innych ciekawych celow np. jak przekazywanie parametrow do procedur, ale to juz inna bajka dla bardziej zaawansowanych
Pozdro
Dexter

Dexter77 napisał:

Po drodze na stosie zachowuje aktualny adres licznika programu zeby wiedzial w ktore miejsce ma wrocic po wykonaniu instrukcji reti informujacej o zakonczeniu obslugi przerwania.Dexter

W procku nic się nie dzieje "po drodze" tylko po kolei. Jak układ przerwań odbięrze przerwanie, które jest aktywne to w pierwszej kolejności na stos odkładany jest licznik rozkazów. W PIC jest jeszcze STATUS. Teraz procesor pobiera adres z wektora przerwań i reszta odbywa się tak jakby był to normalny program czyli rozkaz po rozkazie.
To tyle słowem wyjaśnienia.

0. Stos pozwala m.in zapamiętać kolejność powrotów i zagnieżdżać przerwania i procedury, czego by się nie dało prosto zrobić na rejestrach.

1. Wektory przerwań zależnie od typu procesora mogą być umieszczone na poczatku, końcu programu lub w innym obszarze. W przypadku popularnych ósemek faktycznie na początku

2. W niektórych procesorach zamiast rozkazów wektory przerwań zawierają wyłącznie adresy procedur obsługi. W klasycznym przypadku w tym obszarze umieszczamy rozkaz skoku do procedury obsługi przerwania. W szczególnych przypadkach można tam umieścić całą obsługę przerwania - np. inkrementacja licznika i powrót, włączenie flagi sygnalizującej przerwanie i powrót itp...

3. W procesorach, które automatycznie nie odkładają stanu procesora na stosie, musisz to zrobić programowo, po to by np. nie zgubić stanu flag sprzed przerwania. O rejestrach używanych w obsłudze przerwania zostało już wyżej napisane.

4. W układach z priorytetami przerwania o niższych priorytetach są odkładane do czasu zakończenia obsługi przerwań ważniejszych.

5. Z wielu sztuczek na stosie ciekawą możliwością jest podmiana adresu powrotu z procedury lub obsługi przerwania co pozwala na powrót w zupełnie inne miejsce (np. w systemie wielozadaniowym).

6. W niektórych procesorach oprócz przerwań stricte sprzętowych występują dodatkowo przerwania dla sytuacji wyjątkowych (np. nadmiar przy obliczeniach arytmetycznych) oraz specjalne przerwania programowe służące do wywoływania funcji systemu operacyjnego lub/i debugerów.

Do: MirekCz i Gieneks

Ludzie czytajcie literaturę i nie piszcie jak nie jesteście pewni.
Po kiego grzyba licznik rozkazów ma być odkładany na stos.
Każde przerwanie i rozkazy wywołujące procedury, funkcje czy podprogramy na stos odkładaja tylko i wyłacznie adres powrotu (operacja hardwerowa) , wszystko inne na stosie to już działanie programisty.
Adres powrotu to nie licznik rozkazów.

olekewaagata napisał:

Do: MirekCz i Gieneks

Ludzie czytajcie literaturę i nie piszcie jak nie jesteście pewni.
Po kiego grzyba licznik rozkazów ma być odkładany na stos.
Każde przerwanie i rozkazy wywołujące procedury, funkcje czy podprogramy na stos odkładaja tylko i wyłacznie adres powrotu (operacja hardwerowa) , wszystko inne na stosie to już działanie programisty.
Adres powrotu to nie licznik rozkazów.

Tym nie mniej adres powrotu ma dużo wspólnego z dotychczasowym stanem PC (Program Counter), bo jest on podstawą do obliczenia adresu powrotu, w zależności od kodu aktualnie wykonywanego rozkazu.
Pozdrawiam, Light'I

Brawo olekewaagata. Tak to jest i być powinno. Jak dotychczas chyba żaden z procesorów nie ma zawsze stałej ilości bajtów w rozkazie, stąd i przy przerwaniu nie wiadomo czy powrót z niego to do następnego bajtu, a może do następnego itd. A po co stos - krótko po to bo jest wygodny, i samo sie robi. W różnych procesorach jest co prawda co innego nań odkładane, ale zdejmuje się dokładnie to samo , tyle, że w odwrotnej kolejności. Zabawa ze stosem ma jeszcze jeden ciekawy aspekt przy podprogramach z dużą ilością danych - a po kiego diabła przekazywać te wszystkie dane skoro po wywołaniu podprogramu następne bajty to wskażnik na miejsce gdzie te dane się znajdują i znajdzie się on na szczycie stosu jako adres powrotu z podprogramu - pobrać ze stosu , wykorzystać, zmienić na np. "to co było +2" i z powrotem załadować na stos. Po zakończeniu podprogramu wrócimy nie do bajtu następnego po CALL (tam w sensie rozkazu jest bzdura), ale do tego po modyfikacji i całość wykonuje się jakby sama. Te numery są w wielu wypadkach bardzo wygodne, ale i niebezpieczne - łatwo idzie się w krzaki.

Light­ napisał:

Tym nie mniej adres powrotu

Możemy się umówić, że przed wywołaniem przerwania, albo wykonaniem procedury, w liczniku adresu wyznaczany jest adres następnej instrukcji do wykonania (pomijając procedurę), zresztą tak to się odbywa w logice procesora. Czy to nazwiemy adresem powrotu, czy nową wartością licznika rozkazów, to jest tylko kwestia nomenklatury.

Wracając do zabaw ze stosem, w PDP-11 był taki piękny rejestr, który nosił nazwę rejestru łącznikowego, i który był niejako przedłużeniem stosu. Przy jego pomocy można było w bardzo prosty sposób tworzyć listę odwołań, pozwalającą na ominięcie kilku poziomów powrotu.

frohme napisał:

Jak dotychczas chyba żaden z procesorów nie ma zawsze stałej ilości bajtów w rozkazie.

Oj, bo będę się kłócił, proponuję przejrzeć pdf-y od PIC i AVR - są przedstawiciele o stałej długości rozkazu, ewentualnie rozkaz jest dwa razy większy od standardowej wielkości, no chyba, że coś przeoczyłem.
Pozdrawiam, Light'I