1 From: MX%"antek@mimuw.edu.pl" 1-MAR-1993 15:38:21.16
\r
6 Date: Mon, 1 Mar 93 14:59:27 GMT
\r
7 From: antek@mimuw.edu.pl
\r
8 To: salwicki@pauvx1.univ-pau.fr
\r
23 \^\ \ \ \ \ \ \ \ \ \ \ \"PRZENASZALNY RUNNING SYSTEM NOWEGO LOGLANU\ \ \ \ \ \ \ \ \ \ \^
\r
27 \^\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ NAPISANY W J\(E\"ZYKU C\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \^
\r
43 \^\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \1Antoni Kreczmar\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \^
\r
61 Poni\2x\1szy kr\2o\1tki opis Running Systemu dla \ nowego \ Loglanu \ opiera
\r
64 si\2e \ \1w \ du\2x\1ym \ stopniu \ na \ poprzednich \ dokumentacjach. \ \ Przede
\r
67 wszystkim na opisie Running \ Systemu \ Loglanu-82 \ oraz \ na \ dw\2o\1ch
\r
70 pracach opublikowanych, \ tj. \ G.Cioni, \ "Programmed \ deallocation
\r
73 without \ dangling \ reference" \ IPL \ 18(1984) \ pp.179-187, \ \ oraz
\r
76 M.Krause, \ A.Kreczmar, \ H.Langmaack, \ A.Salwicki, \ M.Warpechowski
\r
79 "Algebraic approach to ...." w Lecture Notes in Computer \ Science
\r
82 Springer 208, pp.134-156. W pierwszej z tych prac \ opisano \ system
\r
85 adresowania \ po\2s\1redniego \ dla \ Loglanu, \ \ a \ \ w \ \ drugiej \ \ dosy\2c
\r
88 \1skomplikowane \ algorytmy \ poprawiania \ \ tablicy \ \ Display \ \ oraz
\r
91 adresowania nielokalnego dla j\2e\1zyk\2o\1w z metodami dziedziczenia \ na
\r
94 r\2ox\1nych poziomach. Bez znajomo\2s\1ci \ tych \ dw\2o\1ch \ prac \ zrozumienie
\r
97 poni\2x\1szego kr\2o\1tkiego raportu jest niezwykle trudne. Radzimy \ wi\2e\1c
\r
100 przed przyst\2a\1pienie do czytania niniejszego tekstu zapozna\2c \ \1si\2e
\r
103 \1z tymi dwiema pracami, \ jak \ r\2o\1wnie\2x \ \1z \ dokumentacj\2a \ \1w \ dw\2o\1ch
\r
106 poprzednich jej postaciach (dla Loglanu-82 w \ pe\2l\1ni \ uruchominego
\r
109 i dla Loglanu-84 w pr\2o\1bnej wersji loglanowej). \,
\r
115 Nowy RS system dla nowego Loglanu \ zosta\2l \ \1napisany \ najpierw \ w
\r
118 Loglanie-82, \ a \ nast\2e\1pnie \ w \ j\2e\1zyku \ C. \ Wyb\2o\1r \ j\2e\1zyka \ C \ by\2l
\r
121 \1nieprzypadkowy. Ot\2ox \1w j\2e\1zyku tym mo\2x\1na wyrazi\2c \ \1wiele \ w\2l\1asno\2s\1ci
\r
124 niskopoziomowych, a posiada \ on \ tak\2x\1e \ wszystkie \ zalety \ j\2e\1zyka
\r
127 wysokopoziomowego. Przet\2l\1umaczenie wersji loglanowej na j\2e\1zyk C
\r
130 nie \ przedstawia\2l\1o \ wi\2e\1kszych \ trudno\2s\1ci, \ umo\2x\1liwi\2l\1o \ natomiast
\r
133 stworzenie bardzo efektywnego systemu \2l\1atwego do przenoszenia. \,
\r
136 RS system napisany \ w \ C \ daje \ mo\2x\1liwo\2sc \ \1wykonywania \ programu
\r
139 loglanowego przet\2l\1umaczonego na j\2e\1zyk C. Taki \ spos\2o\1b \ realizacji
\r
142 Loglanu \ wydaje \ mi \ si\2e \ \1najprostszy. \ Napisanie \ kompilatora \ z
\r
145 Loglanu na C jest \ znacznie \ \2l\1atwiejsze \ ni\2x \ \1napisanie \ pe\2l\1nego
\r
148 kompilatora \ na \ docelow\2a \ \1maszyn\2e\1. \ Problem \ przenoszenia \ jest
\r
151 rozwi\2a\1zany w spos\2o\1b natychmiastowy. Ponadto kompilator taki mo\2x\1e
\r
154 korzysta\2c \1z bogactwa konstrukcji j\2e\1zyka C. Nie b\2e\1dzie problemu ze
\r
157 sta\2l\1ymi, \ \ instrukcjami \ \ \ steruj\2a\1cymi \ \ \ w \ \ \ obr\2e\1bie \ \ \ modu\2l\1u,
\r
160 wej\2s\1ciem-wyj\2s\1ciem, \2l\1a\2n\1cuchami itp. \ Niezwykle \ upro\2s\1ci \ si\2e \ \1sam
\r
163 proces translacji. Wyra\2x\1enia mog\2a \1pozosta\2c \1w prawie niezmienionej
\r
166 postaci - jedynie dost\2e\1p do zmiennych loglanowych b\2e\1dzie wymaga\2l
\r
169 \1wywo\2l\1ywania specjalnych makro - ale proces \2l\1adowania \ rejestr\2o\1w,
\r
172 optymalizacji lokalnej itd. przerzucony zostanie na system \ C.
\r
175 A \ przecie\2x \ \1jest \ to \ system \ niezwykle \ \ efektywny. \ \ Wi\2e\1kszo\2sc
\r
178 \1kompilator\2o\1w C daje kod \ dobrze \ zoptymalizowany. \ W \ ten \ prosty
\r
181 spos\2o\1b mo\2x\1emy wykorzysta\2c \1si\2le \1tego j\2e\1zyka \ zostawiaj\2a\1c \ troski
\r
184 techniczne \ \ \ (rejestry, \ \ \ arytmetyka \ \ \ maszyny, \ \ \ \ etykiety,
\r
187 optymalizacja) systemowi C. \,
\r
193 Opisany poni\2x\1ej system sk\2l\1ada si\2e \1z dwu \ plik\2o\1w \ : \ Rs.c \ oraz
\r
196 Rsdata.h. Plik Rsdata.h jest \ tzw. \ plikiem \ nag\2lo\1wkowym \ (header
\r
199 file). W nim wyra\2x\1ono wszystkie wsp\2o\1lne struktury \ danych \ oraz
\r
202 podstawowe zmienne. Na pliku Rs.c znajduje \ si\2e \ \1natomiast \ pe\2l\1na
\r
205 biblioteka \ \ Running \ \ Systemu. \ \ Tekst \ \ programu \ \ \ loglanowego
\r
208 przet\2l\1umaczony na C musi w\2la\1cza\2c \1za pomoc\2a \1instrukcji \ include
\r
211 plik Rsdata.h. W taki sam spos\2o\1b w\2la\1czany \ jest \ ten \ plik \ przez
\r
225 Warszawa, Sierpie\2n \11988\,
\r
237 2. Opis struktur danych na pliku Rsdata.h
\r
243 Na pliku \ tym \ znajduj\2a \ \1si\2e \ \1deklaracje \ struktury \ prototyp\2o\1w \ i
\r
246 offset\2o\1w. Zajmiemy \ si\2e \ \1najpierw \ struktur\2a \ \ \1prototypu. \ \ Ma \ \ on
\r
249 nast\2e\1puj\2a\1c\2a \1posta\2c\1: \,
\r
255 \4struct \3Prototype
\r
267 \ \4int \3lspan\1, \3rspan\1;
\r
270 \ \4int \3references\1;
\r
273 \ \4int \3decl\1, \3level\1;
\r
276 \ \4int \3lastwill\1;
\r
279 \ \4int \3permadd\1;
\r
282 \ \4int \3Sloffset\1, \3Dloffset\1;
\r
285 \ \4int \3Statoffset\1, \3Lscoffset\1;
\r
288 \ \4int \3handlist\1;
\r
291 \ \4int \3pref\1, \3pslength\1;
\r
300 Atrybut \3kind \1definiuje rodzaj \ prototypu. \ Mamy \ nast\2e\1puj\2a\1ce \ ich
\r
303 rodzaje: CLASS, SUBROUTINE, PROCESS, COROUTINE, HANDLER, \ RECORD,
\r
306 PRIMITARRAY, REFARRAY, SUBARRAY, STRUCTARRAY, POINTARRAY. \ Pi\2ec
\r
309 \1pierwszych nie wymaga wyja\2s\1nie\2n\1. RECORD jest klas\2a \1bez kodu i bez
\r
312 innych modu\2lo\1w zadeklarowanych \ wewn\2a\1trz. \ Ten \ rodzaj \ prototypu
\r
315 istnia\2l \1ju\2x \1w poprzedniej wersji Running Systemu. Ostanich pi\2ec
\r
318 \1rodzaj\2o\1w dotyczy tablic. PRIMITARRAY jest tablic\2a \ \1o \ elementach
\r
321 typu pierwotnego, \ REFARRAY \ jest \ tablic\2a \ \1typu \ referencyjnego,
\r
324 SUBARRAY jest tablic\2a\1, kt\2o\1rej elementami s\2a \1domkni\2e\1cia \ procedur,
\r
327 STRUCTARRAY jest tablic\2a \1o elementach typu z\2l\1o\2x\1onego \ i \ wreszcie
\r
330 POINTARRAY \ jest \ tablic\2a \ \1typu \ \ referencyjnego, \ \ jednak\2x\1e \ \ o
\r
333 elementach daj\2a\1cych adresy po\2s\1rednie bez licznik\2o\1w. \ Taki \ typ
\r
336 dodatkowy wprowadzili\2s\1my w nowej wersji \ RS \ w \ celu \ osi\2a\1gni\2e\1cia
\r
339 wi\2e\1kszej efektywno\2s\1ci kodu. Zamiast \ pe\2l\1nego \ adresu \ wirtualnego
\r
342 [adres po\2s\1redni, licznik] niekt\2o\1re referencje s\2a \ \1postaci \ [adres
\r
345 po\2s\1redni]. \ Nie \ daj\2a \ \1one \ oczywi\2s\1cie \ gwarancji \ \ poprawno\2s\1ci
\r
348 adresowania \ (mo\2x\1e \ wyst\2a\1pi\2c \ \1tzw. \ nieokre\2s\1lona \ \ referencja),
\r
351 nimniej, \ je\2s\1li \ u\2x\1ytkownik \ jest \ pewny \ \ poprawno\2s\1ci \ \ swoich
\r
354 adresowa\2n\1, mo\2x\1e cz\2esc \1lub \ wszystkie \ referencje \ zaznaczy\2c \ \1jako
\r
357 proste. Poniewa\2x \1typy \ tablicowe \ s\2a \ \1rozr\2ox\1niane \ przez \ atrybut
\r
360 \3kind, \1w\2s\1r\2o\1d rodzaj\2o\1w typ\2o\1w pojawi\2l \1si\2e \1tak\2x\1e typ POINTERARRAY. \,
\r
366 Drugim atrybutem prototypu jest \3num\1. Wskazuje on \ pozycj\2e \ \1danego
\r
369 prototypu w tablicy PROT [] definiuj\2a\1cej wszystkie prototypy. \,
\r
375 Atrybuty \3lspan \1i \3rspan \1definiuj\2a \ \1rozmiar \ obiektu \ danego \ typu.
\r
378 Wszystkie obiekty alokowane \ s\2a \ \1w \ tablicy \ M[ \ ]. \ Maj\2a\1c \ adres
\r
381 obiektu \3am \1na lewo mamy rozmiar \ \3lspan\1, \ na \ prawo \ \3rspan\1, \ czyli
\r
384 obiekt \ zajmuje \ elementy \ tablicy \ M[\3am-lspan\1..\3am\1+\3rspan\1]. \ Adres
\r
387 prototypu usytuowany jest zawsze w s\2l\1owie M[\3am\1], tzn. maj\2a\1c adres
\r
390 obiektu na zmiennej \3am\1, w\2l\1a\2s\1nie M[\3am\1] = \ \3num \ \1, \ gdzie \ \3num \ \1jest
\r
393 adresem prototypu tego \ obiektu \ w \ tablicy \ PROT. \ Tablice \ maj\2a
\r
396 \1rozmiar definiowany dynamicznie. W s\2l\1owie \ M[\3am\1] \ jest \ zapisany
\r
399 stosowny \ numer \ prototypu, \ natomiast \ \ dwa \ \ kolejne \ \ s\2l\1owa
\r
402 definiuj\2a \1doln\2a \ \1i \ g\2o\1rn\2a \ \1granice \ wska\2z\1nika. \ Rozmiar \ elementu
\r
405 tablicy w przypadku PRIMITARRAY podawany jest za pomoc\2a \ \1atrybutu
\r
414 Pozosta\2l\1e atrybuty nie s\2a \1konieczne w przypadku tablic.
\r
420 Atrubut \3references \1definiuje struktur\2e \1referencji prototypu. \ Jest
\r
423 to po prostu indeks w tablicy OFF[], kt\2o\1ra \ definiuje \ wszystkie
\r
426 rodzaje struktur referencji (patrz definicja OFF poni\2x\1ej). \,
\r
432 Atrybuty \3decl \1i \ \3level \ \1odnosz\2a \ \1si\2e \ \1do \ struktury \ zagnie\2x\1d\2x\1e\2n
\r
435 \1programu. Mianowicie \3decl \1jest indeksem w PROT \ ojca \ statycznego
\r
438 danego modu\2l\1u, natomiast \3level \1jest g\2le\1boko\2s\1ci\2a \1zagnie\2x\1d\2x\1enia. \,
\r
444 Atrybut \3lastwill \1okre\2s\1la miejsce w module, od kt\2o\1rego rozpoczynaj\2a
\r
447 \1si\2e \1instrukcje lastwill. \ W \ jaki \ spos\2o\1b \ modeluje \ si\2e \ \1kontrol\2e
\r
450 \1sterowania podamy w punktach 4 i 10. \,
\r
456 Nast\2e\1pny atrybut \3permadd \1jest wsp\2o\1lnym adresem dla \ permutacji \ i
\r
459 inwersji permutacji numer\2o\1w displaya. Mianowicie plik \ loglanowy
\r
462 definiuje dwie tablice \3perm\1[] i \3perminv\1[], kt\2o\1re \ musz\2a \ \1zawiera\2c
\r
465 \1te permutacji. \ Przyk\2l\1adowo, \ dla \ \3perm\1[] \ = \ {0,1,2,0,2,1} \ oraz
\r
468 \3perminv\1[] = {0,1,2,0,2,1}, indeks \3permadd\1=0 dla warto\2s\1ci \ \3level\1=2
\r
471 okre\2s\1la permutacj\2e \1{0,1,2} \ (i \ te \ sam\2a \ \1odwrotn\2a\1), \ natomiast
\r
474 \3permadd\1=2 dla \3level \1te\2x \1r\2o\1wnym 2 daje perm={0,2,1} \ (i \ podobnie
\r
477 te sam\2a \1odwrotn\2a\1}. \,
\r
483 Cztery \ kolejne \ atrybuty \ \ (\3Sloffset\1, \ \ \3Dloffset\1, \ \ \3Statoffset\1,
\r
486 \3Lscoffset\1) definiuj\2a \1adresy wzgl\2e\1dne (offsety) czterech zmiennych
\r
489 systemowych Sl, Dl, Statsl i Lsc. Ka\2x\1dy \ modu\2l \ \1posiadaj\2a\1cy \ kod
\r
492 musi \ mie\2c \ \1okre\2s\1lon\2a \ \1pozycj\2e \ \1Sl \ ojca, \ Dl \ \ ojca, \ \ lokalnego
\r
495 sterowania Lsc i licznika Sl syn\2o\1w (Statsl). \ O \ tych \ zmiennych
\r
498 systemowych b\2e\1dziemy m\2o\1wi\2c \1za chwil\2e\1. Tutaj natomiast \ chcieli\2s\1my
\r
501 zwr\2o\1ci\2c \1uwag\2e \1na to, \2x\1e w poprzedniej \ wersji \ RS \ offsety \ tych
\r
504 zmiennych by\2l\1y podawane w prototypie (ich pozycja \ by\2l\1a \ ustalona
\r
507 na ko\2n\1cu obiektu). Wprowadzenie offset\2o\1w zmiennych systemowych do
\r
510 prototyp\2o\1w skomplikuje kompilacj\2e\1, ale przyspieszy i ujednorodni
\r
513 RS. Dost\2e\1p do tych zmiennych \ b\2e\1dzie \ bowiem \ taki \ sam \ jak \ do
\r
516 innych \ zmiennych \ wprowadzonych \ przez \ \ u\2x\1ytkownika \ \ czy \ \ te\2x
\r
525 Atrybut \3handlist \1definiuje list\2e \1handler\2o\1w zadeklarowanych w danym
\r
528 module. Jest to indeks w \ tablicy \ HL[], \ gdzie \ zdefiniowane \ s\2a
\r
531 \1wszystkie takie listy. \ Tablica \ HL \ jest \ typu \ Hlstelem \ postaci
\r
534 nast\2e\1puj\2a\1cej: \,
\r
540 \4struct \3Hlstelem
\r
549 \ \4int \3signlist\1;
\r
564 Atrybut \3hand \1jest indeksem w tablicy \ PROT \ w\2l\1a\2s\1ciwego \ handlera.
\r
567 Natomiast atrybut \3signlist \ \1jest \ indeksem \ w \ tablicy \ SL[] \ typu
\r
570 \3Sgelem\1, \ gdzie \ okre\2s\1lone \ s\2a \ \1numery \ sygna\2lo\1w \ zwi\2a\1zane \ z \ \ tym
\r
573 handlerem. Typ \3Sgelem \1ma posta\2c \1nast\2e\1puj\2a\1c\2a\1: \,
\r
585 \ \4int \3signalnum\1;
\r
600 W ka\2x\1dym elemencie tablicy \ SL[] \ mamy \ numer \ sygna\2l\1u \ \3signalnum\1,
\r
603 kt\2o\1ry jest warto\2s\1ci\2a \1absolutn\2a \1budowan\2a \1przez kompilator. \ Atrybut
\r
606 \3next \1pokazuje na kolejny element takiej \ listy \ w \ SL[]. \ Podobnie
\r
609 zreszt\2a \1atrybut \3next \1w HL[] wskazuje na nast\2e\1pny handler \ zwi\2a\1zany
\r
612 z danym modu\2l\1em. Koniec ka\2x\1dej takiej listy \ (w \ obu \ przypadkach)
\r
615 okre\2s\1la warto\2sc \3next\1=-1 (tak wybrano z uwagi na \ adresowanie \ w \ C
\r
624 Atrybut \3handlist \1wyst\2e\1puje tak\2x\1e w prototypie handlera. \ Okre\2s\1la
\r
627 on jedynie, \ czy \ handler \ ten \ odpowiada \ na \ wszystkie \ sygna\2l\1y
\r
630 (others), \ czy \ \ te\2x \ \ \1jest \ \ deklarowany \ \ jako \ \ handler \ \ dla
\r
633 wyspecyfikowanych \ numer\2o\1w \ sygna\2lo\1w. \ W \ \ pierwszym \ \ przypadku
\r
636 warto\2sc \ \1tego \ atrybutu \ jest \ 1 \ (hanlder \ dla \ \ others), \ \ w
\r
639 pozosta\2l\1ych przypadkach warto\2sc \1tego atrybutu jest 0. \,
\r
648 Dwa ostatnie atrybuty w prototypie ( \ \3pref\1, \ \3pslength\1) \ okre\2s\1laj\2a
\r
651 \1struktur\2e \1prefiksowania. Nie musz\2a \1one \ wyst\2e\1powa\2c \ \1w \ przypadku
\r
654 prototyp\2o\1w dla handler\2o\1w, gdy\2x \1handler nie mo\2x\1e by\2c \1prefiksowany.
\r
657 Atrybut \3pref \1jest indeksem w tablicy PROT modu\2l\1u \ prefiksuj\2a\1cego
\r
660 (-1 gdy nie istnieje), \ atrybut \ \3pslength \ \1jest \ d\2l\1ugo\2s\1ci\2a \ \1ci\2a\1gu
\r
663 prefiksuj\2a\1cego. \,
\r
669 Pozosta\2l\1a do \ om\2o\1wienia \ struktura \ referencji. \ Ot\2ox \ \1z \ powodu
\r
672 wprowadzenia bogactwa typ\2o\1w z\2l\1o\2x\1onych w nowym Loglanie, struktura
\r
675 referencji \ w \ obiektach \ jest \ stosunkowo \ skomplikowana. \ Takie
\r
678 struktury opisuje tablica OFF[] typu \3Offsets\1. \,
\r
693 \ \4int \3size\1, \3num\1;
\r
696 \ \4int \3length\1, \3finish\1;
\r
702 \ \4int \3references\1;
\r
714 Atrybut \3kind \1jest nast\2e\1puj\2a\1cych \ rodzaj\2o\1w: \ SIMPLELIST, \ SEGMENT,
\r
717 REPEATED \ oraz \ COMBINEDLIST. \ SIMPLELIST \ jest \ list\2a \ \ \1zwyk\2l\1ych
\r
720 offset\2o\1w \ zmiennych \ referencyjnych \ w \ obiekcie. \ SEGMENT \ jest
\r
723 szczeg\2o\1ln\2a \1postaci\2a \ \1takiej \ listy, \ gdy \ te \ offsety \ zajmuj\2a
\r
726 \1kolejne miejsca w pami\2e\1ci (ten typ wprowadzili\2s\1my \ ze \ wzgl\2e\1du
\r
729 na tablice referencyjne, jakkolwiek jest \ on \ sprowadzalny \ do
\r
732 przypadku poprzedniego). REPEATED jest \ n-krotn\2a \ \1iteracj\2a \ \1danej
\r
735 struktury referencyjnej. COMBINEDLIST jest list\2a \1by\2c \1mo\2x\1e r\2ox\1nych
\r
738 struktur referencji. \,
\r
744 Atrybut \3size \1okre\2s\1la ca\2l\1kowit\2a \1d\2l\1ugo\2sc \1opisywanej \ struktury \ Dla
\r
747 SIMPLELIST musi to \ by\2c \ \1d\2l\1ugo\2sc \ \1ca\2l\1ego \ obiektu, \ dla \ SEGMENT
\r
750 r\2o\1wnie\2x \1d\2l\1ugo\2sc \1ca\2l\1ego obiektu, dla REPEATED musi to by\2c \ \1d\2l\1ugo\2sc
\r
753 \1powtarzanej struktury, i ostatecznie dla COMBINEDLIST ma to \ by\2c
\r
756 \1d\2l\1ugo\2sc \ \1struktury \ wewn\2a\1trz \ kt\2o\1rej \ podawane \ s\2a \ \1wska\2z\1niki \ \ do
\r
765 Kolejny \ atrybut \ \3num \ \1definiuje \ indeks \ w \ tablicy \ \ OFF \ \ danej
\r
774 Znaczenie atrybutu \3length \1jest \ wieloznaczne. \ Dla \ SIMPLELIST
\r
777 \3length \1jest d\2l\1ugo\2s\1ci\2a \1listy offset\2o\1w. Dla SEGMENT \ \3length \ \1jest
\r
780 pozycj\2a \1pierwszego,a \3finish \1ostatniego elementu \ segmentu. \ Dla
\r
783 REPEATED \3length \1jest \ krotno\2s\1ci\2a \ \1powt\2o\1rzenia \ podstruktury. \ Dla
\r
786 COMBINEDLIST \3length \1jest d\2l\1ugo\2s\1ci\2a \1listy. \,
\r
792 Atrybut \3head \1jest indeksem w tablicy EL[], gdzie \ zakodowane \ s\2a
\r
795 \1listy struktur referencji. Typem tej tablicy jest \3Elem\1: \,
\r
807 \ \4int \3offset\1;
\r
813 \ \4int \3references\1;
\r
822 W tablicy tej atrybut \3offset \1definiuje odpowiedni offset a \ \3next
\r
825 \1jest jak zwykle wska\2z\1nikiem do \ nast\2e\1pnego \ elementu \ listy. \ Dla
\r
828 typu SIMPLELIST ka\2x\1dy taki \ offset \ mo\2x\1e \ by\2c \ \1offsetem \ zmiennej
\r
831 referencyjnej pe\2l\1nej lub tylko adresem po\2s\1rednim, ale tak\2x\1e \ mo\2x\1e
\r
834 by\2c \1offsetem domkni\2e\1cia procedury (czyli pary <SL, adres kodu> ).
\r
837 Gdy atrybut \3references \1jest 0, mamy referencje pe\2l\1n\2a\1, gdy jest \ 1
\r
840 jest to adres po\2s\1redni, wreszcie gdy jest 2 \ jest \ to \ domkni\2e\1cie
\r
849 Dla typu COMBINEDLIST atrybut \3references \1okre\2s\1la indeks w tablicy
\r
852 OFF wskazywanej podstruktury referencji. \,
\r
861 W przypadku typu SEGMENT atrybut \ \3head \ \1mo\2x\1e \ jeszcze \ okre\2s\1la\2c
\r
864 \1rodzaj referencji. Gdy \3head \1= 0, mamy segment pe\2l\1nych referencji,
\r
867 gdy jest 1 jest to segment adres\2o\1w po\2s\1rednich, gdy jest 2 jest to
\r
870 segment domkni\2ec \1procedur.\,
\r
879 Dla ostatniego atrybutu \3references \1w \ typie \ \3Offsets \ \1mamy \ jedno
\r
882 zadanie. Powinien on okre\2s\1la\2c \1dla typu REPEATED indeks w \ tablicy
\r
885 OFF powtarzanej struktury. \,
\r
891 Powy\2x\1szy system wprowadzania \ struktury \ prototyp\2o\1w \ jest \ dosy\2c
\r
894 \1niezr\2e\1czny, je\2s\1li musi by\2c \1wykonany r\2e\1cznie. Troch\2e \1w \ tym \ wina
\r
897 j\2e\1zyka C. Mo\2x\1na by\2l\1o \ wprowadzi\2c \ \1typ \ union, \ kt\2o\1ry \ przypomina
\r
900 rekordy z \ wariantami, \ ale \ w\2o\1wczas \ nie \ mo\2x\1naby \ podawa\2c \ \1tych
\r
903 struktur przez definicje w deklaracji (odp. DATA \ w \ Fortranie).
\r
906 Zatem przyj\2al\1em \ takie \ rozwi\2a\1zanie \ przez \ zwyk\2la \ \1struktur\2e\1. \ Z
\r
909 drugiej strony translator z Loglanu na C mo\2x\1e bez k\2l\1opotu budowa\2c
\r
912 \1tak\2a \1struktur\2e\1. \,
\r
921 3. Struktury Dl i Sl
\r
927 Struktura Dl zachowana jest taka \ jak \ w \ Simuli \ i \ Loglanie-82.
\r
930 Aktywny wsp\2ol\1program jest \2l\1a\2n\1cuchem Dl, zawieszony jest \ cyklem
\r
933 Dl. \ Nowy \ Loglan \ usun\2al \ \ \1Detach, \ \ gdy\2x \ \ \1wprowadzi\2l \ \ \1zmienn\2a
\r
936 \1LAST_ATTACH - \ wskazuj\2a\1c\2a \ \1na \ ostatni \ wsp\2ol\1program \ wykonuj\2a\1cy
\r
939 Attach(X). Zako\2n\1czenie wsp\2ol\1programu \ jest \ sygnalizowane \ b\2le\1dem
\r
942 (propozycja \ \ \ \ Marka \ \ \ \ Warpechowskiego). \ \ \ \ Wykonuje \ \ \ \ \ si\2e
\r
945 \1Attach(LAST_ATTACH) with Cor_Term (coroutine terminated), \ o \ ile
\r
948 LAST_ATTACH \ =/= \ \4none\1, \ w \ \ przeciwnym \ \ razie \ \ wykonuje \ \ si\2e
\r
951 \1Attach(My_Process) \ \ with \ \ Cor_Term. \ \ To \ \ \ rozwi\2a\1zanie \ \ \ jest
\r
954 metodologicznie uzasadnione i najprostsze. \,
\r
960 Dla \ wsp\2ol\1programu \ aktywnego \ warto\2sc \ \1Dl \ jest \ \ \4none\1. \ \ Pr\2o\1ba
\r
963 reaktywacji wsp\2ol\1programu aktywnego \ powoduje \ wys\2l\1anie \ sygna\2l\1u
\r
966 alarmowego. \ Wsp\2ol\1program \ \ zako\2n\1czony \ \ ma \ \ ustawion\2a \ \ \1warto\2sc
\r
969 \1lokalnego sterowania Lsc na 0. \ Pr\2o\1ba \ reaktywacji \ zako\2n\1czonego
\r
972 wsp\2ol\1programu powoduje wys\2l\1anie sygna\2l\1u. Zauwa\2x\1my na \ zako\2n\1czenie
\r
975 omawiania struktury Dl, \ \2x\1e \ Dl-link \ mo\2x\1e \ by\2c \ \1w \ tym \ systemie
\r
978 referencj\2a \1niepe\2l\1n\2a \1(tzn. tylko adresem po\2s\1rednim). \ Zyskujemy
\r
981 w ten spos\2o\1b na pami\2e\1ci i na czasie wykonania programu. \,
\r
987 Struktura Sl link\2o\1w \ tworzy \ drzewo. Problemem s\2a \ \1tylko \ usuwane
\r
990 obiekty procedur, \ funkcji \ i \ blok\2o\1w, \ po \ ich \ terminacji. \ W
\r
993 poprzedniej \ wersji \ przyj\2e\1li\2s\1my \ \ strategi\2e \ \ \1usuwania \ \ takich
\r
996 obiekt\2o\1w bez wzgl\2e\1du na konsekwencje. Mog\2l\1o si\2e \ \1zdarzy\2c\1, \ \2x\1e \ po
\r
999 pewnym \ czasie \ wznawiany \ dobrze \ \ okre\2s\1lony \ \ obiekt \ \ nie \ \ ma
\r
1002 okre\2s\1lonego otoczenia statycznego (Sl link przeci\2e\1ty). \ Umieli\2s\1my
\r
1005 wykry\2c \1takie przypadki, ale nie by\2l\1o to \ rozwi\2a\1zanie \ eleganckie.
\r
1008 Marek Lao \ zauwa\2x\1y\2l\1, \ \2x\1e \ lepiej \ by\2l\1oby \ u\2x\1y\2c \ \1zwyk\2l\1ej \ techniki
\r
1011 licznik\2o\1w referencji tylko \ dla \ tego \ przypadku. \ Mamy \ przecie\2x
\r
1014 \1licznik Statsl (poprzednio inaczej okre\2s\1lony), nale\2x\1y zastosowa\2c
\r
1017 \1go w spos\2o\1b nast\2e\1puj\2a\1cy. \,
\r
1023 Ka\2x\1de otwarcie nowego obiektu zwi\2e\1ksza o 1 \ licznik \ Statsl \ jego
\r
1026 statycznego ojca. Ka\2x\1de zako\2n\1czenie obiektu \ procedury \ (funkcji,
\r
1029 bloku) sprawdza, czy jego Statsl jest 0. Je\2s\1li tak, obiekt \ mo\2x\1na
\r
1032 usun\2ac\1, zmniejszy\2c \1Statsl o \ 1 \ dla \ jego \ ojca \ i \ powt\2o\1rzy\2c \ \1te
\r
1035 operacje dla takiego \ ojca \ (o \ ile \ jest \ to \ obiekt \ procedury,
\r
1038 funkcji lub bloku). Dla usuwanego za pomoc\2a \1kill \ obiektu \ klasy,
\r
1041 sprawdzamy \ najpierw \ jego \ Statsl, \ \ i \ \ post\2e\1pujemy \ \ podobnie.
\r
1044 Pozostaje rozwi\2a\1za\2c \1poprawnie problem usuwania wsp\2ol\1program\2o\1w. \,
\r
1050 Zabicie zawieszonego wsp\2ol\1programu polega na \ zabiciu \ stosownego
\r
1053 cyklu Dl. Najpierw przegl\2a\1damy taki cykl i sprawdzamy, \ czy \ jego
\r
1056 wszystkie obiekty maj\2a \1Statsl \ r\2o\1wny \ 0. \ Je\2s\1li \ nie, \ wywo\2l\1ujemy
\r
1059 sygna\2l \1alarmowy. Je\2s\1li natomiast wszystkie \ s\2a \ \1usuwalne, \ mo\2x\1emy
\r
1062 przyst\2a\1pi\2c \1do kolejnego ich usuwania. Aby \ to \ zrobi\2c \ \1poprawnie,
\r
1065 nale\2x\1a\2l\1oby stosowa\2c \1operacj\2e \1przej\2s\1cia po Sl-\2l\1a\2n\1cuchu dla ka\2x\1dego
\r
1068 obiektu usuni\2e\1tego (tak jak \ dla \ obiektu \ klasy). \ Ale \ przecie\2x
\r
1071 \1mogliby\2s\1my usun\2ac \1jaki\2s \1obiekt jeszcze \ nieusuni\2e\1ty \ z \ usuwanego
\r
1074 w\2l\1a\2s\1nie cyklu wsp\2ol\1programu. Aby unikn\2ac \1tej sytuacji, \ odwracamy
\r
1077 najpierw \ cykl \ wsp\2ol\1programu. \ Zabijaj\2a\1c \ obiekty \ w \ kolejno\2s\1ci
\r
1080 odwrotnej (od g\2l\1owy wsp\2ol\1programu, nast\2e\1pnie syn dynamiczny itd),
\r
1083 mamy pewno\2sc\1, \ \2x\1e \ nie \ usuniemy \ przy \ czyszczeniu \ kolejnych
\r
1086 \2l\1a\2n\1cuch\2o\1w Sl \2x\1adnego pozosta\2l\1ego elementu \ cyklu. \ Wynika \ to \ z
\r
1089 w\2l\1asno\2s\1ci Sl \ i \ Dl \ \2l\1a\2n\1cuch\2o\1w \ - \ nie \ mog\2a \ \1i\2sc \ \1w \ przeciwnych
\r
1092 kierunkach, tzn. je\2s\1li jest Dl droga od A do B to nie ma Sl drogi
\r
1095 od B do A. \ W \ drugiej \ fazie \ usuwania \ wsp\2ol\1programu \ zmieniamy
\r
1098 orientacj\2e \1cyklu. resach \ odpowiednio \ (2,3) \ i \ (1,4),
\r
projects / loglan.git / blob