-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Projekt OUX/C+ rozszerza składnię języka C o struktury przełączania wykonania oraz zawiera bibliotekę funkcji. W implementacji wymagane jest stosowanie ustalonego standardu nazewnictwa zmiennych i funkcji globalnych.
Nazwa OUX pochodzi od liter D Q U X oznaczających kolejno: ‹zadanie›, ‹obiekt›, ‹znacznik stanu›, ‹raport›.
Symbole z wielkich liter są piktogramami, w których są dwa kierunki: pionowy i poziomy. Pionowy z góry na dół to przepływ wykonania, a poziomy z lewej oznacza program, a z prawej system. Wszystkie proste symbole to:
- A - deklaracja czegoś
- B - czekanie na coś
- C - przełącznik (‘preprocesora’)
- D - ‹zadanie›
- E - ‹moduł›
- F - aktywacja czegoś
- G - wstępny przebieg przepływu wykonania / ‹raport linii›
- H - ‹system›
- I - ‹procedura›
- J - definicja ‘preprocesora’
- K - ‹zdarzenie›
- L - dezaktywacja czegoś
- M - utworzenie czegoś
- N - wytworzenie formy czegoś stratnie
- O - pętla
- P - zmiana czegoś
- Q - ‹obiekt›
- R - odczyt czegoś (wywołujący zmianę)
- S - ‹zmienna›
- T - sprawdzenie czegoś (test)
- U - ‹znacznik stanu›
- V - ‹nierealizacja›
- W - wyrzucenie czegoś
- X - ‹raport›
- Y - ‹cykler›
- Z - ‹typ› ‹zmiennej›
Stosowane w składni symbole są zawarte w plikach: “compile/E_cplus_S_machine.h” i “compile/E_cplus_S_language.h”.
Nazwy globalne mają format: “E_” nazwa ‹modułu› “_” symbol “_” nazwa, i dowolna ilość “_” symbol “_” nazwa.
System gwarantuje wykonywanie się w każdej chwili tylko jednej struktury wykonania, a przełączanie następuje w wyznaczonych liniach, np. w instrukcji oczekiwania na ‹raport›.
Na ‹moduł› składa zwykle kilka plików mających wspólny początek nazwy do znaku “-”.
‹Zadanie› definiuje się następująco:
D( moduł, nazwa_zadania )
{
I_D
{
}
}
Zwykle definiuje się ‹zadanie› czekające na ‹raport› i wykonujące coś po jego otrzymaniu:
D( moduł, nazwa_zadania )
{ X_M( moduł, nazwa_raportu );
I_D
{ X_B( moduł, nazwa_raportu )
break;
}
X_W( moduł, nazwa_raportu );
}
‹Zadanie› tworzy i usuwa ‹raport›, na który czeka, a inne ‹zadanie› deklaruje użycie ‹raportu›, który emituje.
‹Obiekt› definiuje się w osobnym pliku ‹modułu›, zawierającym zwykle kilka ‹obiektów›.
‹Obiekt› składa się z ‹procedur› jego utworzenia, wyrzucenia i funkcji ‹obiektu›.
‹Znacznik stanu› najpierw się definiuje i inicjuje:
struct
{ unsigned U_R( nazwa, nazwa_stanu ) :1
}struktura;
U_L( struktura.nazwa, nazwa_stanu );
albo:
B U_L( nazwa, nazwa_stanu );
A następnie w pętli wykonania wzbudza go:
U_F( struktura.nazwa, nazwa_stanu );
albo:
U_F( nazwa, nazwa_stanu );
Po to, by później, poza pętlą, go obsłużyć:
if( U_E( nazwa, nazwa_stanu ))
{
}
albo obsłużyć go w innym ‹zadaniu›:
if( U_E( struktura.nazwa, nazwa_stanu ))
{
}
Dostępne jest szereg instrukcji ‹nierealizacji›, które odpowiadają sposobowi obsługi błędów wywołań ‘uniksowych’.
Instrukcją ‹nierealizacji› otacza się instrukcję wywołania systemowego, na przykład:
VO1( read( fd, buf, count ))
{ VO1( close(fd) ){}
return 1;
}
W przypadku nierealizacji (błędu) wywołania ‘uniksowego’ jest wypisywany ‹raport linii› ze standardowym opisem błędu.
‹Raport linii› jest to linia tekstu wypisywana po wykonaniu danej linii. Są dwa rodzaje ‹raportów linii›:
- synchroniczny
- asynchroniczny, ale zachowujący kolejność w grupie raportów asynchronicznych
Definiuje się je odpowiednio:
G_();
oraz
G();
Po której to definicji następuje w tej samej linii dowolna liczba definicji wypisywania wartości zmiennych, na przykład:
G(); Gd( zmienna_liczbowa );
Programy znajdują się i mogą być dodawane w podkatalogach katalogu “program”.
W katalogu należy utworzyć łącze do pliku “Makefile” z obecnego już podkatalogu innego programu.
- GNU “make”
- “perl”
- “awk”
- narzędzia podstawowe środowiska ‘unix’ z katalogów “/bin” i “/usr/bin”
- zainstalowana dokumentacja “man” wywołań ‘uniksowych’
Podczas pierwszej ‘kompilacji’ jest tworzona baza danych plików nagłówkowych potrzebnych dla każdego wywołania. Dlatego nie trzeba dodawać instrukcji #include dla tak znalezionych wywołań.