Szarym od mżawki świtem Fri, 30 May 2014 09:12:18 +0200, Andrzej W.
wyrzucił pustą ćwiartkę i oznajmił:

> W dniu 2014-05-30 04:35, A.L. pisze:
>> Procedyra obslugi pzrerwania mzoe zmienic wartosc jakiegos elementu
>> pamieci ktory moze byc testowany przez funkcje F. W zaleznosci of tego
>> elementu pamieci funkcja F mzoe po sobie "posprzatac' Jedyny problem
>> to taki, ze jak funkcja F sie wykonuje, to nei wladomo w ktorym
>> momemncie nastapi pzrerwanie. Wiec nei da sie procedury F pzrerwac
>> natychmniast i z neij wyjsc.
>
> To jest oczywiste i czyste podejście.
> Ja chciałbym mieć coś co pozbędzie się funkcji F bez jej wiedzy i zgody.
> Czyli z funkcji obsługi przerwania wrócimy nie w miejsce w którym główny
> program został zatrzymany ale do punktu B.
> Problemem jest posprzątanie po F.

Dokładnie: można w procedurze obsługi przerwania zamiast tak jak
zazwyczaj wraca się z przerwania po prostu robić co innego. Pytanie
jest faktycznie jak posprzątać, a tu brak danych. Zazwyczaj byłoby to:
- jeżeli return adress i rejestry F są na stosie: podmienić i iret
(instrukcja bodajże 8086).
- stos wypadałoby zresetować. Przed wykonaniem F wypadałoby zapisać
SP i jakąś magiczną trampoliną po przerwaniu przywrócić SP sprzed F,
albo lepiej: zapisać sobie w znajomym miejscu rejestry i SP sprzed
wykonania F i w procedurze obsługi przerwania a) sub sb, ile-trzeba,
b) przywrócić pozstałę rejestry, c) jakoś zakończyć obsługę przerwania
- hardware: wypadałoby posprzątać wszystko co F robiła z hardware,
ale jak rozumiem przerywa się F bo coś jej i tak ze sprzętem nie idzie,
może jakiś reset? reinicjalizacja?

No a potem jak dobrze pójdzie mamy stan taki jakby F nigdy nie była
wykonana...

Wszystko co napisałem powyżej zależy też od samego CPU, mechanizmu
przerwań, reguł obsługi rejestrów, zestawu instrukcji itp.

> Wygląda na to, że ten pomysł może przynieść więcej problemów niż ich
> rozwiązać.
> Zostanę chyba przy WDT...

Tak czy inaczej bez odrobiny assemblera się nie da, chyba że przez setjmp.

--
Edek