PLEX (programming language)

rdf:langString PLEX

rdf:langString PLEX (ang. Programming Language for EXchanges) – strukturalny język wysokiego poziomu opracowany w Ericssonie. Służy do programowania central telefonicznych. Jest rozwijany od lat 70. XX wieku. Używany w centralach telefonicznych AXE Ericssona. Występuje w dwóch odmianach. Na procesorach centralnych (Central Processor - CP) AXE wykorzystywana jest odmiana języka o nazwie Plex-C. Natomiast w modułach rozszerzeń EMRP 8-bitowa wersja Plex-M. Projektantem języka był Göran Hemdahl. Programy w PLEX-ie wykonywane są jako pewna liczba współbieżnych zadań, komunikujących się między sobą za pomocą zdarzeń nazywanych sygnałami. W rzeczywistości współbieżność ta jest pozorna. Zadania umieszczane są w jednej z czterech kolejek, o zróżnicowanym priorytecie i wykonywane . Sygnały za pomocą których komunikują się zadania mogą być bezpośrednie lub buforowane. Sygnał bezpośredni można porównać do instrukcji skoku. Sygnały buforowane powodują utworzenie nowego zadania i umieszczenie go w kolejce. Sygnały można też podzielić, na pojedyncze (single) i łączone (combined). Sygnał łączony rozpoczyna zadanie, po wykonaniu którego sterowanie powraca do miejsca wywołania sygnału. Język PLEX wbrew pozorom jest językiem dość niskiego poziomu i nie posiada mechanizmów zabezpieczających "system operacyjny" przed nieprawidłowo skonstruowanym oprogramowaniem. Stąd też na programiście spoczywa ciężar odpowiedzialności za pisanie kodu w zgodzie z wytycznymi producenta (opisanymi szczegółowo w dokumencie Design Rules). Istnieje wiele reguł z których najważniejszą jest nieprzekraczanie maksymalnego czasu obsługi pojedynczego sygnału (liczonego w instrukcjach kodu maszynowego) na danym poziomie wykonania (A, B, C, D). Przekroczenie maksymalnego czasu powoduje wymuszenie restartu centrali, co wiąże się z obniżeniem dostępności i jakości oferowanych usług. Wykonanie dłuższej sekwencji (np. budowanie tzw. Idle List w różnych blokach funkcjonalnych) musi być co pewien czas przerywane wysyłaniem sygnału CONTINUE, co umożliwia obsługę pozostałych sygnałów w kolejce. Drugą co do istotności regułą jest nieprzekraczanie maksymalnej ilości sygnałów wysłanych podczas obsługi pojedynczego sygnału przychodzącego. Naruszenie tej reguły może doprowadzić do przepełnienia kolejki sygnałów, co z kolei również prowadzi do restartu. Tego typu błąd jest trudny do wyśledzenia, gdyż występuje zwykle podczas silnego obciążenia centrali, a z faktu przepełnienia kolejki trudno jest wprost wywnioskować który blok został źle napisany. Ciekawą cechą języka (wspieraną sprzętowo przez procesor centralny, CP) jest zdolność do kontrolowanego zwalniania zasobów w sytuacjach wyjątkowych, bez konieczności restartu centrali, tzw. FORLOPP (szw. förlopp -- przebieg zdarzeń). Procesor posiada specjalny rejestr FIR (Forlopp Register), który przechowuje identyfikator bieżącego "wątku" wykonania. Znacznik ten jest propagowany poprzez sygnały do wszystkich bloków programowych biorących udział w danej funkcjonalności. W każdym z bloków, alokowane zasoby są znakowane bieżącą zawartością rejestru FIR. Jeśli którykolwiek z bloków wykryje nieprawidłowy stan wykonania (np. otrzyma sygnał którego nie oczekiwał), może wywołać funkcję FLERROR, która stworzy loga przydatnego w trouble-shootingu, zawierającego ostatnie sygnały wysyłane w danym wątku oraz wszystkie dane powiązane z tym wątkiem. Aplikacja może też uruchomić sama procedurę anulowania "wątku" i zwalniania wszystkich zasobów z nim powiązanych (FLRELEASE) lub w przypadku błędu krytycznego (typu użycie "Null pointera") sam system automatycznie uruchamia tę procedurę. Dzięki temu, nie każda błędna sytuacja musi skończyć się restartem całego systemu, a jedynie selektywnym zwolnieniem zasobów. Inną odmianą kontroli wykonania wątku jest kontrola czasu wykonania zadania (nie należy mylić z czasem obsługi pojedynczego sygnału). Przykładem mogą być komendy wydawane przez operatora centrali. Funkcja FLAUDITSTART, znajdująca się na początku kodu obsługującego daną komendę, inicjuje monitorowanie czasu wykonania zadania (tu komendy operatora). Jeśli wykonanie potrwa dłużej niż podany czas maksymalny, dojdzie do automatycznego wygenerowania błędu TIMEOUT AT FLAUDIT i zwolnienia zasobów (FLRELEASE). Ponieważ niektóre komendy mogą mieć bardzo zróżnicowany czas wykonania, istnieje możliwość programowego zwiększenia limitu czasu (funkcja FLAUDITEXTEND), jeśli przetwarzanie komendy tego wymaga. W przypadku pomyślnego zakończenia wykonania zadania, monitorowanie jest wyłączane funkcją FLAUDITSTOP. Obsługą funkcjonalności FORLOPP zajmuje się blok Forlopp Manager (MFM).