Polskie Towarzystwo Informatyczne
NUMER ARCHIWALNY:     3-4 / 45 -46 rok V | marzec-kwiecień 1986
Archiwum
Menu chronologiczne Menu tematyczne


Polskie Towarzystwo Informatyczne

Listy do Redakcji '
Odpowiedź na kilka uwag do artykułu_o systemie CP/M

 

                Po przeczytaniu “Kilku uwag…” o moim artykule, napisanych przez kol. Mariusza Klappera z Krakowa, długo zastanawiałem się, jak na nie zareagować.* Trudno mi było odróżnić krytycyzm od krytykanctwa. Odniosłem wrażenie; że kolega M. Klapper nie uchwycił celu, jaki przyświecał mi przy pisaniu tego artykułu. Był to artykuł poglądowy, a nie skrót dokumentacji systemu CP/M–80. Nie pisałem w nim o swoich sukcesach w pracy z tym systemem i jego poprawianiu, ale o jego naturalnych cechach wynikających z intencji autorów, a nie domorosłych podrabiaczy. Z drugiej strony, w uwagach kol. M. K. odczułem nutę ironii, która niestety, w moim przekonaniu, wynika z niechęci do czytania literatury fachowej i niedostępności dla wielu osób oryginalnych materiałów dokumentacyjnych dotyczących zaawansowanego oprogramowania dla mikrokomputerów.

                Aby nie być gołosłownym, postaram się rozstrzygnąć wszystkie wątpliwości.
1.     Czy system operacyjny CP/M–80 jest “dojrzały”, czy nie — to spór o sformułowanie. Faktem jest, że do dzisiaj system ten jest najbardziej popularny na rynku mikrokomputerów ośmiobitowych. Wersja 2.2 nie przestała być oferowana przez wielu dostawców oprogramowania, pomimo pojawienia się systemu CP/M+ (wersja 3.0, r. 1982). Każdy system operacyjny ma wady mniej lub bardziej widoczne i uciążliwe. Ale z perspektywy sześciu lat można powiedzieć, że jeżeli program nie jest dalej modyfikowany, a po trzech latach oferowania go na światowym rynku pojawia się jego następca, o zupełnie innej budowie, zachowując całkowitą zgodność “w dół” ze swoim poprzednikiem, to mamy do czynienia z produktem dojrzałym, przynajmniej w kategoriach amerykańskiego rynku oprogramowania.
2.     Zgadzam się, że system CP/M może być poprawnie zainstalowany w pamięci operacyjnej o pojemności mniejszej niż 10 KB; wystarczy pamięć 6,5 KB, aby umieścić w niej sam system operacyjny, tylko po co? Systemy operacyjne nie istnieją same dla siebie, są oprogramowaniem pomocniczym, z punktu widzenia interesów typowego użytkownika. Z kolei, największy z programów pomocniczych — asembler ASM dostarczany wraz z systemem operacyjnym, potrzebuje dodatkowej pamięci 8 KB do załadowania i dodatkowego obszaru do pracy. Tak więc 20 KB PAO jako wymaganie instalacyjne wynika nie z rozrzutności, lecz ze zdrowego rozsądku.
3.     Obszar między adresem 80H a 0FFH na stronie zerowej jest domyślnym buforem transmisji dyskowych i buforem poleceń operatorskich, realizowanych przez moduł CCP. Nie znalazłem rozbieżności między tym, co napisałem, a dokumentacją systemu operacyjnego CP/M wydaną przez Digital Research i dostarczaną wraz z oprogramowaniem. Tego samego zdania co ja jest także p. Thom Hogan, autor książki pt. Osborne CP/MR user guide (wyd. 2), która się ukazała nakładem Osborne/McGraw–Hill.
4.     Każdy system operacyjny (a więc także jego moduły) jest programem, w myśl definicji podawanych przez autorów dostępnych w Polsce książek traktujących o systemach operacyjnych (zob. Alan C. Shaw: Projektowanie logiczne systemów operacyjnych, WNT, Warszawa 1980 lub S. E. Madnick, J. J. Donovan: Systemy operacyjne, PWN, Warszawa 1983).
5.     Znakowe strumienie we/wy oraz zarządzanie pamięcią realizuje moduł BDOS. Moduł CCP korzysta z tych funkcji realizując zlecenia operatora. Osobom mającym co do tego wątpliwości, proponuję próbę wykonania którejkolwiek z tych funkcji po usunięciu z pamięci modułu BDOS.
6.     Tak jak zaznaczyłem na początku, zamierzałem napisać nie skrót dokumentacji, lecz artykuł przeglądowy: skoro jednak wymaga tego sytuacja, pewne problemy wyjaśnię szczegółowo. Moduł CCP nie zezwala na “nakrycie” żadnej części systemu CP/M tylko w fazie ładowania “programu użytkownika” do pamięci. W fazie wykonania każdy z modułów CP/M, nawet BIOS, może być “nałożony” przez realizowane zadanie, ale w sposób ściśle kontrolowany. Moduł CCP kontroluje tylko zgodność serii i generacji modułów BDOS i CCP w chwili poprzedzającej realizację zlecenia operatora. Po przekazaniu sterowania do “programu użytkownika” CCP jest zbędny i może być usunięty z pamięci. Jeżeli nie zostanie uszkodzony, a program realizowany odtworzy stos systemowy, to powrót do systemu operacyjnego może być wykonany przez instrukcję RET. W przeciwnym razie jest konieczny “ciepły” start systemu. “Nakładanie” modułu BDOS uniemożliwia wprawdzie korzystanie z systemu plików, ale nie przeszkadza w używaniu dysków w sposób bezpośredni przez BIOS i powrót do systemu operacyjnego przez “ciepły” start. Wykorzystanie przez “program użytkownika” obszaru pamięci zajmowanego przez BIOS odcina możliwości korzystania z systemu we/wy wbudowanego do systemu CP/M i zmusza do wykonania “zimnego” startu w celu powrotu do systemu operacyjnego. Ale i ten przypadek jest sensowny, jeśli np. program nie używa standardowych procedur we/wy zawartych w obszarze modułu BIOS lub ma wbudowane własne programy we/wy. Tak więc zarzuty w p. 6 i 7 uważam za nieporozumienie.
7.     Wyliczenie wykonane przez kol. M. Klappera w p. 8 jego uwag świadczy o braku informacji na temat możliwości CP/M 2.2 w zarządzaniu dużymi zbiorami. Przy standardowym zainstalowaniu jeden deskryptor w skorowidzu może faktycznie opisywać tylko 16 KB pamięci dyskowej, ale nie jest to konieczność. Dokładna analiza bloku parametrów dysku DPB opisana w szóstym tomie dokumentacji firmowej systemu operacyjnego CP/M pod tytułem “CP/M 2 Alteration” wyjaśnia, że:
   maksymalna wielkość jednostki alokacji na dysku wynosi 16 KB (zakres 1–16 KB);
   liczba “logicznych” ekstendów o rozmiarze 16 KB opisywanych przez jeden deskryptor w skorowidzu może wynosić od 1 do 16;
   każdy logiczny ekstend — to 128 sektorów dyskowych po 128 B;
   jeden deskryptor może opisywać maksymalnie 256 KB przestrzeni na dysku, stąd do opisu 8 MB zbioru potrzeba 32 deskryptorówv skorowidzu, a to nie jest dużo!
Można się zgodzić, że 8 MB w jednym zbiorze to dużo, ale nawet przy tak wielkich zbiorach czynnikiem limitującym przepustowość systemu i efektywność zarządzania plikami będzie szybkość i pojemność pamięci dyskowej; a nie kompetencja systemu CP/M.
8.     Wystąpienie dwóch identycznych identyfikatorów pliku na dysku, tzn. ta sama nazwa, typ i numer ekstendu w jednym obszarze logicznym dysku (numer użytkownika), jest ewidentnym błędem systemowym wykrywanym przez wszystkie programy usługowe systemu CP/M. Programy te wykrywają istnienie nieunikalnej nazwy na dysku w chwili kreowania pliku i eliminują możliwość wykonania takiej operacji. Nie przypuszczam, aby kol. M. K. uważał, że nazwa pliku napisana małymi literami jest identyczna z nazwą napisaną dużymi literami. System CP/M rozróżnia te sytuacje!
9.     Istnienie możliwości stworzenia 16 niedostępnych obszarów użytkowników na dysku (User 16 — User 31) uważam za nieporozumienie. Wszak chodzi nie o eliminację części powierzchni dysku z użycia, lecz o jej logiczny podział.
10. Pliki “tymczasowe” o typie $$$ są zawsze usuwane przez programy usługowe, które je tworzą, w sytuacji normalnego zakończenia wykonywanej czynności. W przypadkach awaryjnych plik o takim typie może pozostać w skorowidzu dyskowym, ale nie zmienia to sytuacji, że jest on bezużyteczny, niepoprawnie zapisany lub błędny. Jeśli istnieje, należy go wykasować.
                Uważam, że dyskusja lub polemika z autorami publikacji jest wskazana, a czasami wręcz niezbędna, ale nie zawsze musi być publiczna. Podpisuję swoje publikacje umożliwiając taką wymianę zdań. Uważam, że dyletanctwa nie sposób brać nikomu za złe, jeśli nie towarzyszy mu złośliwość.
                Kto ma rację, osądźcie drodzy Czytelnicy sami.
Andrzej Majewski
(Instytut Informatyki Politechniki Gdańskiej)
 

                Od Redakcji. Ze względu na bardzo szczupłe ramy naszego biuletynu, zamieszczoną powyżej odpowiedzią kol. A. J. Majewskiego jesteśmy zmuszeni zakończyć dyskusję nad jego artykułem pt. “Dyskowy system operacyjny CP/M”. Brak miejsca nie pozwala redakcji na opublikowanie następnego, równie jak pierwszy obszernego listu kol. M. Klappera z uwagami do drugiej części artykułu. Proponujemy kol. Klapperowi, a także ew. innym zainteresowanym czytelnikom, nawiązanie bezpośrednich kontaktów z Autorem.



* Zob. Biuletyn PTI 1985, nr 9 i 10 (artykuł) oraz 1986, nr 1-2 (list do Redakcji) Przyp. red.
 
Archiwum PTI Ewa Łukasik ( elukasik@cs.put.poznan.pl) Grzegorz Przybył ( grzegorz.przybyl@wp.pl ) www.pti.org.pl Kontakt PTI ( pti@pti.org.pl )
Tutorial


Tutorial

Wyszukiwanie

Całość
tylko prodialog
tylko biuletyny
tylko konferencje
tylko multimedia
tylko sprawozdania
tylko uchwały
tylko zawody
tylko zjazdy
pozostałe treści

Rodzaj przeszukiwania
Słowa kluczowe
Pełen tekst

pelen zakres dat
ograniczony zakres
od:

do:




Kontakty

Instytut Informatyki

Polskie Towarzystwo Informatyczne

Nasz Skrzynka Pocztowa

+ - D A