Przyjrzyjmy się współpracy procesora z klawiaturą. Procesor wykonuje rozkaz „Czytaj znak z klawiatury"**). Jeśli jest wciśnięty jakiś klawisz, to odpowiedni kod zostanie wczytany, czyli umieszczony w umówionym miejscu pamięci komputera. Teraz drobna dygresja: kiepski program po wykonaniu rozkazu czytania idzie dalej i po prostu przetwarza pobrany (?) znak. Dobry sprawdzi, czy rzeczywiście coś zostało wczytane, bo może żaden klawisz nie był wciśnięty. W tym wypadku zaczyna działać w pętli — wykonuje wczytanie i sprawdzenie poprawności aż do momentu faktycznego wczytania znaku. Unika w ten sposób przetwarzania śmieci. Takie sprawdzanie poprawności wykonania operacji jest niezbędne gdy sami programujemy obsługę urządzenia (np. w języku wewnętrznym maszyny).
Jeśli natomiast komunikujemy się z nim za pośrednictwem procedur wejścia/wyjścia dostarczonych przez język programowania czy system operacyjny, to problemy te są już załatwione. Np. instrukcja INPUT w BASIC-u czeka aż operator wpisze dane — nie musimy w naszym programie umieszczać pętli oczekiwania na pojedyncze znaki.
Wróćmy do wczytywania: klawisz wciśnięty, znak wczytany. Jeśli jednak, po wczytaniu każdego znaku program musi wykonać dłuższe rachunki, to może się okazać, że operator pisze szybciej niż komputer czyta i zanim jeden znak zostanie wczytany naciśnie już następny. Oczywiście część znaków ginie. Chyba że wyposażymy klawiaturę w niewielką pamięć, w której będą zapisywane naciskane klawisze. Procesor komputera będzie pobierał znaki nie bezpośrednio z klawiatury, lecz z tej pamięci, czyli właśnie BUFORA. Pamięć buforowa służy więc do amortyzacji różnicy prędkości między pisaniem a wczytywaniem znaków (w omówionym przypadku różnica na korzyść operatora). W przypadku klawiatury typowe długości bufora to 8 lub 16 znaków.
KONIEC GUBIENIA ZNAKÓW
Oczywiście w dalszym ciągu istnieje możliwość przepełnienia bufora, np. jeśli program liczy przez godzinę i nic nie wczytuje. Dlatego niezbędny jest układ sygnalizujący brak miejsca na nowe znaki i blokujący wprowadzanie. (Zwykle w takiej sytuacji komputer reaguje piskiem na każde naciśnięcie klawisza). UWAGA: nie należy mylić zawartości bufora klawiatury, ze znakami, które już są napisane i odbite na ekranie, lecz jeszcze nie zostały przesłane do przetwarzania naciśnięciem ENTER (lub RETURN). Znaki siedzące w buforze klawiatury nie zostały jeszcze zauważone przez resztę komputera, "wyskoczą na ekran" gdy procesor przestanie być zajęty i poświęci im uwagę.
Wniosek praktyczny jest następujący: jeśli pracujemy z programem konwersacyjnym, który sterujemy np. naciskając spację, i program, obliczając coś, przestał reagować na klawiaturę, to nie warto wciskać tej spacji wielokrotnie. Pierwsza już siedzi w buforze klawiatury i czeka na pobranie. Następne też tam trafiają i będą po kolei pobierane i interpretowane jako następne polecenia, co zwykle wyśmienicie wyprowadza program w maliny.
WĄSKIE GARDŁO - WOLNA DRUKARKA
Popatrzmy teraz co się dzieje na wyjściu, czyli na współpracę komputer — drukarka. Komputer jest w stanie produkować wyniki dużo szybciej niż drukarka przenosić je na papier. Często jednak produkcja tych wyników jest nierównomiernie rozłożona w czasie. Rozpatrzmy następujący przykład: pewien program rozwiązuje 10 równań. Obliczenia dla jednego równania trwają 100 sekund, a po ich zakończeniu wysyła na drukarkę 10 linii wydruku (czas przesłania komputer — drukarka będziemy systematycznie pomijać). Wydruk jednej linii zajmuje drukarce 5 sekund.
Po otrzymaniu znaku drukarka wysyła komputerowi sygnał: „Brak gotowości do przyjmowania znaków", czym zmusza go do oczekiwania. Następny znak można wysłać dopiero gdy drukarka napisze poprzednio wysłany i wyśle komputerowi sygnał: „Gotowe, wysyłaj". Przy tym schemacie obliczenia i wydruk dla jednego zestawu zajmują: 100s + 10linii*5s = 150s a dla dziesięciu zestawów 1500s.
Jeśli jednak możemy wysyłać na raz całą linię (drukarka ma bufor na tyle znaków ile mieści się w linii), a następną linię gdy tylko skończy się druk poprzedniej, to komputer musi czekać na drukarkę tylko do momentu wysłania ostatniej linii, czyli podczas drukowania dziewięciu, razem 9*5s = 45s, a czas wykonywania obliczeń wynosi 10*(100s + + 45s) = 1450s, a więc nieco lepiej.
Zwróćmy uwagę, że bufor został wprowadzony jakby między urządzenie bezpośrednio drukujące a komputer. Komputer wpisuje swoje dane do bufora z jednej strony, a z drugiej strony tegoż bufora są one pobierane do druku.
Co się stanie, jeśli powiększymy pojemność bufora drukarki do pełnych dziesięciu linii? Spróbujcie się najpierw zastanowić sami. Gotowe? To jedziemy. Po zakończeniu obliczeń dla jednego zestawu, komputer zaczyna przesyłać wyniki na drukarkę. Dopóki bufor nie będzie pełen drukarka przyjmuje je bez problemów, czyli (w bardzo krótkim czasie, któ ry pomijamy) wszystkie dane zostały wyprowadzone. Przynajmniej z punktu widzenia procesora, który natychmiast przystępuje do następnych rachunków. W tym czasie drukarka, pracując równolegle z procesorem, przenosi zawartość bufora na papier. Czas wykonywania obliczeń: 10* 100s = 1000s. Po tym czasie komputer może rozpocząć następne zadania. Na koniec drukowania musimy poczekać jeszcze dodatkowe 50s.
Efekt ostateczny: poprawa efektywności wykorzystania komputera o prawie jedną trzecią, a więc bardzo znaczna.
Koszty: wyposażenie drukarki w dodatkową pamięć, wielkości rzędu kilku kilobajtów oraz układy obsługi bufora. Przy dzisiejszych cenach pamięci i elektroniki są to koszty nieznaczne.
Myślę, że już nikt nie ma wątpliwości: jak to jest możliwe? Program już się skończył, widać to na monitorze, a drukarka jeszcze pracuje.
TROCHĘ DODATKOWYCH KŁOPOTÓW
Rola bufora drukarki jest jednak bardziej złożona. Bywa bowiem całkiem odwrotnie — komputer generuje po kilka znaków, w sporych odstępach czasu. Mogą one być gromadzone w buforze drukarki i wyprowadzane na papier dopiero gdy linia zostanie zapełniona, lub komputer prześle bezwzględny rozkaz: „Koniec linii". Właściwie nie ma to dla nas znaczenia, ale czasami zdarza się tak, że program wyśle część znaków na drukarkę, lecz zanim zapełni lub zakończy linię, jego realizacja zostaje przerwana, np. przez wystąpienie błędu. Wtedy część znaków „znika", wydaje się, że działanie programu zostało przerwane nie tam, gdzie faktycznie to nastąpiło i szukamy błędu nie tam gdzie jest naprawdę. Piszę o znikaniu w cudzysłowie, gdyż tak naprawdę, to te znaki są. Gdzie? Oczywiście w buforze drukarki. Naprawdę mogą zniknąć dopiero gdy wyłączymy ją z sieci. Jeśli nie, to brakujące znaki pojawią się na początku następnego wydruku.
Podobna sytuacja może wystąpić jeśli po ostatniej instrukcji pisania w programie nie wyprowadzamy znaku końca linii. Może ale nie musi — dobry kompilator lub interpreter po napotkaniu instrukcji kończącej program, może spowodować opróżnianie buforów wszystkich urządzeń.
Buforowanie nie ogranicza się tylko do drukarki i klawiatury. Wprost przeciwnie, jest to technika bardzo rozpowszechniona. Stosujemy ją wszędzie tam, gdzie współpracują ze sobą urządzenia o różnych prędkościach działania, aby zoptymalizować wykorzystanie urządzeń, zmniejszyć czas wykonywania obliczeń i wreszcie zapobiec gubieniu informacji, gdy urządzenie wolniejsze nie nadąża i nie jest w stanie zatrzymać pracy szybszego.
Andrzej Pilaszek