Tajemnice ATARI - ST FORUM

Na choinkę... BOMBKI


    Zapewne nieraz zdarzyło Ci się, drogi Czytelniku, zauważyć na ekranie swojego monitora rysunek przedstawiający kilku bomb, być może nawet wpadłeś wtedy w panikę i pomyślałeś: "to musi być wirus" i szybko sięgnąłeś po program antywirusowy, lub, co gorsza, szybko sformatowałeś dysk. Taki obrazek często można oglądać w przypadku świeżo upieczonych posiadaczy STówki. Co to są bomby i dlaczego się pojawiają - ten artykuł próbuje tłumaczyć.

    Każdy, kto trochę pracuje z komputerem, zetknął się z sytuacją, kiedy program "wylatuje", "zawiesza się", "pada". Siedzimy wtedy przed monitorem, i nie pozostaje nic innego jak nacisnąć klawisz RESET i rozpocząć prace od nowa. Dlaczego program "pada"? Wynika to z prostej przyczyny, że komputer zawsze wykonuje dokładnie to, co mu się każe, a nie to, co się ma na myśli. Niektóre nie wykryte błędy programisty doprowadzają do wystąpienia sytuacji wyjątkowych, np. dzielenia przez zero, które normalnie powoduje "pójście w maliny". W Atari ST, zanim dojdzie do takiej sytuacji, dzieje się wiele rzeczy, które maja za zadanie nie dopuścić do katastrofy, jaką jest "zawieszenie się" systemu. To wszystko za sprawą procesora Motorola 68000, którego twórcy założyli, że jeśli coś będzie nie w porządku, to system powinien sam się wybronić, a przynajmniej wybrnąć z kłopotliwej sytuacji z możliwie małymi stratami. Gdy dzieje się coś niedobrego, zostaje uruchomiony program ratunkowy, czyli tzw. obsługa sytuacji wyjątkowych (exception handling). Takim zdarzeniem jest np. wspomniane dzielenie przez zero. Po określeniu rodzaju błędu uruchamiana jest odpowiednia procedura. Najczęściej jest to zatrzymanie programu. Gdy jest to niemożliwe, na scenie pojawiają się bomby. Ich ilość informuje o rodzaju błędu (patrz tabela). Oprócz tego następuje zapis do pamięci RAM o właśnie zaistniałej nieprawidłowości. Może to być pomocne przy określaniu przyczyny "wypadku". Ale zostawmy te sprawy programistom. Zwykłego przeciętnego użytkow-nika może interesować, co to właściwie są stany wyjątkowe. "Wyjątki" są to głównie przerwania wewnętrzne generowane wtedy, gdy wewnętrzne mechanizmy procesora wykryją nieprawidłowości spowodowane realizacją programu:

* dzielenie przez zero,
* przekroczenie zakresu danych,
* odwołanie do nieprawidłowego adresu,
* napotkanie na pułapkę zastawioną przez użytkownika,
* próba wykonania rozkazu zarezerwowanego dla innego trybu,
* przekroczenie limitu wskaźnika tablicy danych,
* próba wykonania nie zdefiniowanego rozkazu.

    Co z tego wynika dla szarego użytkownika? Raczej niewiele, i dlatego część teoretyczną potraktowałem czysto informacyjnie, bez dokładnego omawiania poszczególnych wektorów przerwań i adresów pod którymi zapisywane są informacje o błędach.

A co w praktyce?

    Nie można zdecydowanie powiedzieć, jaka liczba bomb pojawia się na ekranie najczęściej. Fakt pozostaje faktem, że pojawiają się one często w programach niedopracowanych, np. po dość intensywnym wystawianiu na próbę "idiotoodporności", czyli po zmuszaniu programu do reagowania na bezsensowne działania, co potwierdza przyczynę ich pojawiania się (odpowiedź na błędy). Często programy z kategorii shareware czy public domain nie wytrzymują takiego testu i "wylatują". Oczywiście nie jest to regułą, gdyż także w przypadku programów firmowych można napotkać na liczne błędy, zwłaszcza we wczesnych wersjach, albo w przypadku braku odpowiednio dużej wolnej pamięci. Zdarza się, że program odmawia posłuszeństwa w przypadku uruchomienia na komputerze z inną wersją systemu TOS. Reakcją na taką sytuację jest również rząd ślicznych bomb. Inną przyczyną są błędy pochodzące od nośnika magnetycznego. Co prawda istnieją odpowiednie sposoby korekcji błędów (CRC), ale często w trakcie uruchamiania systemu okazuje się, że pokazują się bomby, i nic złego dalej się nie dzieje. Tym większe może być nasze zdziwienie, gdy ukaże się normalny obraz Desku. To znaczy, że system potrafi sobie poradzić w pewnych przypadkach z niektórymi błędami całkiem dobrze. Także często spotykamy bomby na ekranie piracko kopiowanych gier, co może wskazywać na to, że program został "odbezpieczony" w niezbyt dokładny sposób. Jak zwykle dużo zależy od nośnika, zwłaszcza w przypadku gier całodyskowych i dyskietek "no name" zapisywanych bez weryfikacji.

    Z tego wszystkiego, co napisałem wcześniej, wynika, że bomby to właściwie nic innego jak efekt pracy systemu ochrony przed błędami i nie należy się dziwić ich istnieniu. Nie sposób podać jakiejś konkretnej recepty na uniknięcie takich "niespodzianek", trzeba po prostu nauczyć się żyć z bombami w zgodzie! Oprócz sygnalizacji błędu w sposób symboliczny (bomby), zdarza się, że zostaje wyświetlone okno dialogowe z konkretnym numerem błędu, i jest to tzw. meldunek błędu TOSu. Takie komunikaty najczęściej wyświetlają programy napisane w GFA Basicu, przy czym nie mąią one nic wspólnego z numerami błędów, które spotykamy podczas uruchamiania programu w edytorze GFA Basic. Poniżej prezentujemy listę tych błędów:

1 błąd ogólny
2 napęd dyskowy nie odpowiada, przekroczenie czasu oczekiwania
3 nieznany rozkaz
4 błąd sumy kontrolnej
5 nieważny rozkaz
6 nie odnaleziono ścieżki
7 nie rozpoznany format dyskietki
8 nie odnaleziony sektor
9 brak papieru (w drukarce)
10 błąd zapisu
11 błąd odczytu
12 błąd ogólny 12
13 dyskietka zabezpieczona przed zapisem
14 zmieniono dyskietkę
15 nieznane urządzenie
16 wykryto zły sektor
17 włożyć inną dyskietkę
32 nieważny numer funkcji
33 nie znaleziono danych
34 nie znaleziono nazwy ścieżki
35 za dużo otwartych plików
36 dostęp nie jest możliwy
37 nieprawidłowy znacznik
39 pełna pamięć
40 nieprawidłowy adres
46 nieprawidłowe określenie napędu
49 nie ma dalszych danych
64 błąd zakresu GEM-DOS
65 wewnętrzny błąd GEMDOS
66 to nie jest program w zapisie binarnym
67 błąd bloku pamięci

    I to tym razem tyle, jeśli chodzie błędy. Zainteresowanych tym tematem odsyłam do wcześniejszych numerów "Komputera", na podstawie których niniejszy artykuł został opracowany, a także literatury traktującej o procesorze MC 68000, życząc jak najmniej "bombowych" programów.

ilość bomb opis
2 Błąd szyny
Próba dostania się do nielegalnego obszaru pamięci lub do układów zarządzających pamięcią.
3 Błąd adresu
Próba pobrania słowa lub "długiego" słowa od adresu nieparzystego.
4 Nielegalna instrukcja
Wykonanie nieważnego rozkazu maszynowego dla MC 68000.
5 Dzielenie przez zero
System operacyjny przeważnie pozwala na odzyskanie kontroli przez program aplikacyjny po wystąpieniu tego błędu.
6 Instrukcja CHK
Przekroczenie zakresu
7 Instrukcja TRAPV
Wykrycie ustawienia bitu nadmiaru V rejestru statusu.
8 Naruszenie przywileju
Próba wykonania przez program użytkownika instrukcji przewidzianej dla innego trybu procesora.
9 Śledzenie
Jeśli ustawiony jest bit śledzenia w rejestrze statusu, to po każdej wykonanej instrukcji wywoływany jest stan śledzenia.



Maciej Żurawski



Powrót na start | Powrót do spisu treści | Powrót na stronę główną

Pixel 2002