\section{Architektur}

Die Funktionalit"at der Modulverwaltung ist "uber drei Moduln
verteilt: {\itshape tyDepend}, {\itshape tlObject}, {\itshape
tlLibrary}.  Ihre Beziehungen untereinander und zu anderen wichtigen
Moduln des Compilers sind in Abbildung~\ref{abb_import} dargestellt.
Die auf den ersten Blick etwas verwirrend erscheinenden Beziehungen
zwischen der Modulverwaltung und dem Rest des Compilers sind
verst"andlich, wenn die Aufgaben der einzelnen Moduln gekl"art sind.
Nach den Ausf"uh\-rung zu den einzelnen Teilen der Modulverwaltung
gehe ich kurz auf den Zusammenhang mit anderen Moduln des Compilers
ein.

\begin{figure}[ht]
\centering\mbox{\epsfig{file=import.eps}}
\caption{Importbeziehungen der Komponenten\protect \footnotemark 
der Modulverwaltung}
\label{abb_import}
\end{figure}
\footnotetext{Um die Darstellung m"oglichst "ubersichtlich zu halten, 
wurden Moduln und die zugeh"origen Schnittstellen jeweils zusammengefa"st.}

\subsection {tlObject}

\label{tlObject}
\begin{sloppypar}
Im Modul {\itshape tlObject}\/ werden die "ubersetzten Moduln und
Schnittstellen verwaltet.  Dies beinhaltet das Speichern und Laden auf
bzw.\ vom Sekund"arspeicher und den entsprechenden Abgleich mit dem
Objektspeicher.  Es werden die nach dem Importieren und Binden von
Komponenten n"otigen Anpassungen der Typinformation und der de-Bruijn
Indizes vorgenommen.  Bei diesen Vorg"angen ist gew"ahrleistet, da"s
die importierten Komponenten zu denen im Objektspeicher 
''passen'', also zusammen mit diesen "ubersetzt wurden und nicht mit
anderen Versionen dieser Objekte.  Jeder Komponente ist eine Art
Versionsnummer zugeordnet, die sich aus der Systemzeit ableitet.  Man
darf sie allerdings nicht mit einer Version im Sinne einer
Versionsverwaltung wie z.~B.\ SCCS\footnote{SCCS: ''Source Code
Control System''.} oder RCS\footnote{RCS: ''Revision Control
System''.} verwechseln.
\end{sloppypar}

Gleichfalls ist es nicht m"oglich, da"s ein Modul mit einer
ge"anderten Komponente arbeitet, ohne es neu zu "ubersetzen.  Dies ist
auch dann nicht m"oglich, wenn sich die "Ande\-rungen bzw.\
Erweiterungen nicht auf den von dem Modul benutzten Teil beziehen.
Alte Versionen eines Moduls kann der Compiler nicht ansprechen, auch
wenn diese mit Hilfe eines Versionskontrollprogramms verwaltet werden,
da der Compiler stets die gleiche Datei anspricht.  Diese wird
von einer eventuell neu erzeugten Version "uberschrieben.

Zentrale Datenstruktur von {\itshape tlObject}\/ ist zum einen
{\itshape Import}, das eine kompilierte Einheit repr"asentiert.
Daneben kann "uber {\itshape Map}\/ auf den Link-Vektor, die
Wurzelbibliothek, das Verzeichnis aller im Objektspeicher
befindlichen Komponenten und auf den Objektspeicher selbst zugegriffen
werden.  "Uber den Link-Vektor, ein indiziertes Verzeichnis, sind der
Wert eines Moduls, sein Bytecode und seine Literale erreichbar.  Nur
wenn ein Modul in den Link-Vektor eingetragen ist, kann es auch
referenziert werden.  {\itshape Map}\/ ist "uber die Schnittstelle
nicht nach au"sen sichtbar.  Zugriffsprozeduren f"ur die
Wurzelbib\-liothek sind deshalb nicht in {\itshape tlLibrary}\/
sondern in {\itshape tlObject}\/ enthalten.

\subsection {tyDepend}

Das Modul {\itshape tyDepend}\/ stellt die Verbindung zwischen in
Quelltextform befindlichen Moduln, Schnittstellen und Bibliotheken und
deren Objektdateien und importierten Komponenten her.  Dies geschieht
durch die Datenstruktur {\itshape Info}, die f"ur jede Komponente eine
Liste der durch sie importierten Komponenten und Informationen "uber
die Konsistenz von Quelltext und Objektdatei enth"alt.  Die
Abh"angigkeiten zwischen den Komponenten, die durch die
Importbeziehungen entstehen, werden in einem Abh"angigkeitsgraphen
abgebildet, der als Hash-Tabelle implementiert ist.  Sie stellt eine
Verbindung zwischen dem Namen einer Komponente und deren {\itshape
Info}-Struktur her.

Die durch die Schnittstelle bereitgestellten Prozeduren {\itshape
makeLibraries}\/ und {\itshape make}\/ sorgen f"ur die
"U\-ber\-setzung der Bibliotheken bzw.\ der Schnittstellen und Moduln.
Der Compiler verhindert unn"otige "Ubersetzungen dadurch, da"s der
Zeitstempel von Quelltext und Objektdatei zur "Uberpr"u\-fung der
Konsistenz herangezogen wird.  Eine "uber dem Quelltext berechnete
Pr"ufsumme (Fingerprint) gibt weiter dar"uber Aufschlu"s, ob der Code
signifikant ge"andert wurde (vgl.\ Abschnitt~\ref{sec_fingerprint}).
Hiermit sind "Anderungen gemeint, die "uber Hinzuf"ugen von Leerzeilen
und Kommentaren hinausgehen.

\subsection {tlLibrary}

\begin{sloppypar}
Tycoon bietet die M"oglichkeit, Schnittstellen und Moduln in
Bibliotheken zusammenzufassen (vgl.\ Abschnitt~\ref{sec_bibliothek}).
Bibliotheken k"onnen wiederum in anderen Bibliotheken enthalten sein
\cite{tycoon_po}.  Die Verwaltung der Bibliotheken geschieht im Modul
{\itshape tlLibrary}.  Es repr"asentiert die durch die Bibliotheken
aufgebaute hierarchische Struktur durch eine entsprechende
Datenstruktur.  Eine weitere wichtige Aufgabe besteht darin, zu
pr"ufen, ob eine Schnittstelle oder ein Modul korrekt in der
Bibliothek definiert ist.  Dazu m"ussen alle von der Komponente
importierten Schnittstellen und Moduln auch in deren
Sichtbarkeitsbereich sein, also vor dieser in der Bibliothek definiert
werden.  Sind alle Komponenten korrekt definiert, keine Komponenten
doppelt vorhanden und gibt es keine Verweise auf nicht deklarierte
Komponenten, so kann die Bibliothek inklusive ihrer enthaltenen
Bibliotheken "ubersetzt werden.  Dazu wird die oben erw"ahnte
Datenstruktur aufgebaut.
\end{sloppypar}

Wie auch im Modul {\itshape tlObject}\/ f"ur "ubersetzte Einheiten
gibt es hier analoge Prozeduren zur Verwaltung von Bibliotheken auf
Sekund"arspeichern.

\subsection {Schnittstelle zur Modulverwaltung}

\begin{sloppypar}
Abbildung~\ref{abb_import} deutet an, da"s die oben behandelten Moduln
eine Einheit bilden.  Sie werden dennoch nicht "uber eine einzige
Schnittstelle angesprochen, was durch die Einf"uh\-rung eines weiteren
Moduls und durch die Aufl"osung der Importbeziehung von {\itshape
tyExec}\/ zum Modul {\itshape tyDepend}\/ m"oglich w"are.  Vielmehr
bleibt die Aufteilung der Aufgaben "uber die Moduln {\itshape
tyDepend}, {\itshape tlObject}, {\itshape tlLibrary}\/ auch in den
"ubergeordneten Komponenten sichtbar.
\end{sloppypar}

Im Modul {\itshape tyDoCommand}\/ werden die auf dem Toplevel
eingegebenen {\itshape do}-Kommandos behandelt.  Diese lassen sich,
soweit sie die Modulverwaltung betreffen, unterteilen in die
systemgenerierenden Kommandos {\itshape do make}\/ und {\itshape do
makeLibraries}\/ ({\itshape tyDepend}), Kommandos zum Laden, Linken und
Binden ({\itshape tlObject}) und zum Zugriff auf die Wurzelbibliothek
({\itshape tlLibrary}).

Das einzige Modul, das sowohl Funktionalit"at von der Modulverwaltung
nutzt als auch bereitstellt, ist {\itshape tyExec}. Einerseits mu"s
zum "Ubersetzen einer Komponente deren Sichtbarkeitsbereich gepr"uft
werden, wozu wiederum die Wurzelbibliothek ben"otigt ({\itshape
tlLibrary}), die "ubersetzten Komponenten im Link-Vektor eingetragen
und Typinformation der bereits definierten Komponenten abgefragt
werden ({\itshape tlObject}).  Andererseits wird das "Ubersetzen einer
Komponente ({\itshape executeUnit} in {\itshape tyExec}) durch
{\itshape do make}\/ angesto"sen ({\itshape tyDepend}).  Diese
Beziehung ist in Abbildung~\ref{abb_import} gestrichelt dargestellt.

Eine weitere Aufgabe von {\itshape tyExec}\/ im Zusammenhang mit der
Modulverwaltung ist das Ausf"uhren von Toplevel-Bindungen.  Die hierzu
notwendigen Zugriffe und Ver"anderun\-gen der Typinformation werden
durch das Modul {\itshape tlObject}\/ realisiert.

Lediglich um die im initialen Toplevel enthaltenen Bezeichner zu
erlangen, wird {\itshape tlObject}\/ in {\itshape tlTopLevel}\/
importiert.  "Ahnliches gilt f"ur {\itshape tyTopLevel}, das au"serdem
die Wurzelbibliothek neu setzt.

