Programowanie: Przerywanie długotrwałych operacji klawiszem BREAK

From Atariki

Wersja z dnia 21:45, 10 cze 2014 Mono (Dyskusja | wkład) (styl.) ← Previous diff		Aktualna wersja Mono (Dyskusja | wkład) (→Kody błędów)
Linia 31:		Linia 31:
	'''UWAGA!''' '''U_SFAIL''' w żaden sposób nie raportuje przepełnienia wewnętrznego stosu zarejestrowanych procedur obsługi błędów należy więc pamiętać, iż takich procedur obsługi może być maksymalnie 10.		'''UWAGA!''' '''U_SFAIL''' w żaden sposób nie raportuje przepełnienia wewnętrznego stosu zarejestrowanych procedur obsługi błędów należy więc pamiętać, iż takich procedur obsługi może być maksymalnie 10.
		+
		+	== Klawisz BREAK ==
	OS w przypadku naciśnięcia klawisza BREAK powoduje wyzerowanie komórki IRQSTAT ($11). Można więc wykorzystując opisany wyżej mechanizm łatwo zaimplementować funkcjonalność przerywania dowolnego długotrwałego procesu za pomocą wciśnięcia klawisza BREAK.		OS w przypadku naciśnięcia klawisza BREAK powoduje wyzerowanie komórki IRQSTAT ($11). Można więc wykorzystując opisany wyżej mechanizm łatwo zaimplementować funkcjonalność przerywania dowolnego długotrwałego procesu za pomocą wciśnięcia klawisza BREAK.
Linia 54:		Linia 56:
	Oczywiście ustawianie własnej pułapki przez '''U_SFAIL''' nie jest obowiązkowe. Wyjątek rzucony przez '''U_FAIL''' przechwyci w takiej sytuacji poprzednio zarejestrowana procedura lub w ostateczności systemowa procedura obsługi błędów.		Oczywiście ustawianie własnej pułapki przez '''U_SFAIL''' nie jest obowiązkowe. Wyjątek rzucony przez '''U_FAIL''' przechwyci w takiej sytuacji poprzednio zarejestrowana procedura lub w ostateczności systemowa procedura obsługi błędów.
		+
		+	== Kody błędów ==
		+
		+	Do '''U_FAIL''' w akumulatorze przekazuje się kod błędu. Kody te dzielone są na dwie logiczne grupy:
		+
		+	* wartości dodatnie (0..127) oznaczają kody statusu operacji,
		+	* wartości ujemne (128..255, czy też inaczej -128..-1) oznaczają kody błędów.
		+
		+	W przypadku gdy rzucony wyjątek obsługuje procedura systemowa, wtedy wyłącznie w przypadku wyrzucenia kodu błędu następuje wypisanie komunikatu (wg pliku zdefiniowanego w zmiennej środowiskowej '''$SYSERR''' - standardowo jest to CAR:SYSERR.MSG) na ekran konsoli.
		+
		+	Jeśli program wywoływany jest z poziomu polecenia wsadowego zwrócony kod statusu można testować za pomocą warunku '''IF ERROR'''. Szczegóły opisane są w 5 rozdziale [http://sdx.atari8.info/index.php?show=en_docs instrukcji użytkownika] p.t. "Command Processor - szersze możliwości".
		+
	[[Kategoria:Programowanie Atari 8-bit]]		[[Kategoria:Programowanie Atari 8-bit]]
	[[Kategoria:Niezbędnik kodera]]		[[Kategoria:Niezbędnik kodera]]

---

Aktualna wersja

SpartaDOS X posiada mechanizmy pozwalające programiście elegancko obsługiwać sytuacje wyjątkowe. Służą do tego procedury opisane w 4 rozdziale podręcznika programowania p.t. "Obsługa błędów".

Zazwyczaj używa się ich przy przechwytywaniu sytuacji wyjątkowych występujących podczas operacji na plikach, jednakże można z powodzeniem wykorzystać ten mechanizm do generowania sytuacji wyjątkowych we własnych procesach.

Wystarczy ustawić własną obsługę błędu za pomocą U_SFAIL i z wnętrza własnej procedury wywołać fukcję U_FAIL z kodem błędu w akumulatorze:

protectedroutine:
  lda ?catchad
  ldx ?catchad+1
  jsr U_SFAIL
  
  jsr routine
  
  jmp U_XFAIL

?catchad .dw catchroutine

catchroutine:
  ...           ;obsługujemy błąd
  rts

;a to procedura generująca błąd
routine:
  ...           ;coś robimy
  
  lda #ERROR    ;i generujemy błąd
  jmp U_FAIL

W przypadku wygenerowania błędu funkcja U_FAIL przekazuje sterowanie natychmiast do procedury obsługi, a stan stosu odtwarzany jest tak, aby powrót nastąpił do procedury wywołującej kod zakładający pułapkę - w tym przypadku będzie to punkt wywołujący protectedroutine.

UWAGA! U_SFAIL w żaden sposób nie raportuje przepełnienia wewnętrznego stosu zarejestrowanych procedur obsługi błędów należy więc pamiętać, iż takich procedur obsługi może być maksymalnie 10.

Klawisz BREAK

OS w przypadku naciśnięcia klawisza BREAK powoduje wyzerowanie komórki IRQSTAT ($11). Można więc wykorzystując opisany wyżej mechanizm łatwo zaimplementować funkcjonalność przerywania dowolnego długotrwałego procesu za pomocą wciśnięcia klawisza BREAK.

W kodzie długotrwałej procedury należy co jakiś czas sprawdzać zawartość IRQSTAT i jeśli została wyzerowana rzucić błąd (np. BREAK KEY ABORT)

routine:
  ...
  jsr erroronbreak
  ...
  rts
 
erroronbreak:
  lda IRQSTAT
  seq
  rts
  dec IRQSTAT
  lda #$80      ;BREAK KEY ABORT
  jmp U_FAIL

Warto zauważyć, iż po wykryciu wciśnięcia klawisza BREAK wstawiana jest wartość $FF do IRQSTAT. Ustawiana jest ona przez OS podczas normalnej pracy i po obsłudze wciśnięcia klawisza BREAK podczas procedur I/O (procedury edytora ustawiają tam wartość $80 po obsłudze wciśnięcia klawisza BREAK, lub $88 po obsłudze wciśnięcia kombinacji klawiszy CTRL+3). Jest to o tyle istotne, że funkcje konsoli sprawdzają tę komórkę i również generują błąd wciśnięcia klawisza BREAK, więc brak jej obsługi spowodowałby nieoczekiwane wyrzucenie błędu przy pierwszej próbie użycia np. PRINTF, PUTC, itp.

Oczywiście ustawianie własnej pułapki przez U_SFAIL nie jest obowiązkowe. Wyjątek rzucony przez U_FAIL przechwyci w takiej sytuacji poprzednio zarejestrowana procedura lub w ostateczności systemowa procedura obsługi błędów.

Kody błędów

Do U_FAIL w akumulatorze przekazuje się kod błędu. Kody te dzielone są na dwie logiczne grupy:

• wartości dodatnie (0..127) oznaczają kody statusu operacji,
• wartości ujemne (128..255, czy też inaczej -128..-1) oznaczają kody błędów.

W przypadku gdy rzucony wyjątek obsługuje procedura systemowa, wtedy wyłącznie w przypadku wyrzucenia kodu błędu następuje wypisanie komunikatu (wg pliku zdefiniowanego w zmiennej środowiskowej $SYSERR - standardowo jest to CAR:SYSERR.MSG) na ekran konsoli.

Jeśli program wywoływany jest z poziomu polecenia wsadowego zwrócony kod statusu można testować za pomocą warunku IF ERROR. Szczegóły opisane są w 5 rozdziale instrukcji użytkownika p.t. "Command Processor - szersze możliwości".