-*- text -*-
Datum: Montag, 17. Oktober 1994, 00:18:23
======================================================================

moegliche Zyklen bei Deklarationen:

1.)
TYPE a=b;
TYPE b=INTEGER;

Typdeklarationen werden (noch) nicht vertauscht, wenn es Abhaengigkeiten gibt.

==> noch nicht geloest.


2.)
TYPE abc = (a, b, c, d, e)
CONFIGURATION confabc [b..e];

Da Typdeklarationen hinter die Configurations-Deklarationen verschoben
werden, sind die Konstanten a bis e zum Zeitpunkt der
Config-Deklaration noch nicht bekannt.

==> geloest! Alle Enumeration-Konstanten (hier a bis e) werden zu Beginn
definiert. Nur die Typdeklaration (hier abc) selbst kommt dann spaeter
bei den Typen.


3.)
CONST a=b+1;
CONST b=6;

Konstantendeklarationen werden (noch) nicht vertauscht, wenn es
Abhaengigkeiten gibt.

==> noch nicht geloest.
======================================================================

Deklarationen werden grundsaetzlich umsortiert, damit
Vorwaertsreferenzen moeglichst zu Rueckwaertsreferenzen
werden: 1. Enumeration Constants, 2. normale Constants (ohne
array/record Initializer), 3. Configurations, 4. Connections,
5. Typen, 6. Constants als array/record Initializer, 7. Variablen,
8. Prozeduren.

Momentanes Problem: innerhalb der Typen und innerhalb der Konstanten
wird nicht sortiert (siehe oben).

Idee um auch hier zu sortieren:

Sinngemaess: Pruefen, ob Typ Vorwaertsreferenz ist. Wenn Pointer auf
record: ok, dann aber auch "struct" angeben, nicht nur Typ. Sonst:
einfach weitermachen.

Jeder Typ, der tatsaechlich hingeschrieben werden kann, wird
markiert. Die ganze Ausgabe wird nun fuer die jeweils noch nicht
markierten Typen wiederholt, bis alle markiert sind oder in einem
Durchlauf kein neuer Typ mehr geschrieben und markiert werden
konnte. In letzterem Fall ist ein Zyklus enthalten, der nicht
aufgeloest werden kann. (Frage: kann das ueberhaupt vorkommen? Es wird
doch schon frueher mal auf Zyklen abgeprueft.)

Problem: Markierungen muessten Attribute sein. Vielleicht klappt aber
auch eine Version, bei der die Markierung irgendwie durch Rekursion
"gemerkt" werden kann. In einer Liste von tIdents geht es auf jeden Fall.

======================================================================

Prinzip der Configurations:

Configgroup und Dimensionen extra als Felder deklariert und
initialisiert -> Configuration kann auch initialisiert werden.

Trotzdem noch Aufruf von INIT_CONFIGURATION noetig, da Anzahl layers
fuer Activeset und damit Activeset selbst erst zur Laufzeit
bestimmbar. Dann Allozierung ueber p_malloc.


======================================================================

Prinzip der Vektor-Variablen:

Vektorvariable ist im Prinzip ein Array mit der Anzahl layers in dieer
Configgroup. Allerdings koennen (wie im Activeset oben) die Layers
erst zur Laufzeit bestimmt werden, darum werden Vektorvariablen nur
als Zeiger deklariert und dann beim Aufruf INIT_VAR per p_malloc
alloziert.

======================================================================

moegliche Optimierungen:

Wenn bei parallelem IF der THEN-Teil leer ist, kann man gleich die
inverse Bedingung fuer den active-set berechnen und direkt die ELSIFs
bzw. den ELSE-Teil aufrufen.

Evtl. koennen verschiedene FOR_ALL_ACTIVE-Loops, die nacheinander
kommen, aber auf der gleichen Config-Group operieren, zu einer
zusammengefasst werden. Achtung! Manchmal muessen sie einzeln bleiben
(z.B. bei Precalculations, wo sie ja extra auseinandergezogen werden).

Evtl. koennen verschiedene ENVs zusammengelegt werden, z.B. wenn
mehrere IFs auf der gleichen Configuration hintereinander folgen.


