% Studienarbeit von Markus Breilmann
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel 3: Die Funktionsweise der Tycoon-Maschine


\chapter{Die Funktionsweise der Tycoon-Maschine}
\label{Kap. Die Funktionsweise der Tycoon-Maschine}

Tycoon-Programme werden in Form eines Byte-Codes (TVM-Code) persistent im Objektspeicher gehalten und durch die ``Tycoon Virtual Machine'' ausgef"uhrt. Die virtuelle Maschine stellt zur Programmausf"uhrung im wesentlichen folgende Funktionen zur Verf"ugung:
\begin{itemize} 
\item Die Datenein- und -ausgabe in Form von Datenstr"omen (streams) in Verbindung mit
Bildschirm/Tastatur (Konsole), Dateien und Sockets.
\item Einbindung von Funktionen externer Programmiersprachen (z.B. C oder C++).
\item Kommunikation mit dem jeweiligen Objektspeicher.
\item Die Unterst"utzung von Multithreading durch die Implementation von Coroutinen.
\item Speicherzugriffsmechanismen, die sich aus dem Speicherbedarf der vorher genannten
Funktionen ergeben.
\item Eine rudiment"are Ausnahmebehandlung im Fehlerfall.
\end{itemize}

\section{Namenskonventionen der Tycoon-Maschine}
\label{Aufbau der TM}

Die Tycoon-Maschine unterscheidet Funktionen auf drei Abstraktionsniveaus. Die Funktionen eines Niveaus bilden dabei eine logische Komponente: das Runtime-System, die eigentliche ``Tycoon Virtual Machine'' und eine Unterst"utzung systemnaher TL-Befehle. 

Die TVM ist in der Sprache C realisiert. Der Source-Code ist in mehreren Modulen (Dateien) organisiert, wobei Funktionen eines Aufgabenbereiches in einem Modul zusammengefa"st werden (z.B. Funktionen zur Speicherverwaltung zum Modul {\sf ``rtmemory''}). Die ersten beiden Buchstaben des Dateinamens zeigen die Zuordnung der Datei zu einer der drei Komponenten der Tycoon-Maschine an: {\sf RT} f"ur Runtime-System, {\sf TM} f"ur ``Tycoon Virtual Machine'' und {\sf TL} f"ur Tycoon-nahe Funktionen (Tycoon Language). Abbildung \ref{picTVM} gibt einen "Uberblick "uber die genannten Komponenten.

Die Namen exportierter Entit�ten eines Moduls wie Funktionen oder globale Variablen werden durch Kombination des Modulnamens (Dateinamens) und des eigentlichen Namens der Entit�t gebildet (z.B. {\sf ``rtmac\_sample''}). Funktionsnamen werden dabei klein ({\sf ``tsp\_open\-Store''}), Typnamen gro� geschrieben ({\sf ``rtstring\_T''}). Makros werden g�nzlich in Gro�buchstaben notiert ({\sf ``rtstring\_LENGTH(s)''}).

\section{Die Tycoon-Maschine}
\label{Komponenten der TM}

Die Tycoon-Maschine besteht aus drei Komponenten, dem Laufzeitsystem (RT, Runtime-System), der ``Tycoon Virtual Machine'' (TM) und der Unterst"utzung von Tycoon-Language-Funktionen (TL, siehe Abbildung \ref{picTVM}).

\begin{figure}
\psbild{0.8#1}{.}{tvm.epsf}
\caption{Die Komponenten der ``Tycoon Virtual Machine''}
\label{picTVM}
\end{figure}

\subsection{Runtime-System}
\label{Runtime-System}

Das Runtime-System bildet die unterste Ebene des Systems und es stellt u.a. Funktionen f"ur Textein- und -ausgabe, Dateizugriffe und Speicherverwaltung bereit (siehe Tabelle \ref{tableRT}. Die in dieser Schicht zusammengefa�ten Funktionen werden von ann�hernd jeder Applikation ben�tigt und sind am wahrscheinlichsten von Betriebssystemabh�ngigkeiten betroffen. Die Schnittstelle besteht daher aus abstrakten Funktionen, die im einfachsten Fall direkt auf Betriebssystemaufrufe oder Standardfunktionen abgebildet werden. Auf einigen Plattformen mu� das gew�nschte Verhalten nachgebildet werden. Derartige �nderungen bleiben durch die Kapselung auf eine Stelle im Gesamtsystem beschr�nkt und werden so vor �bergeordneten Funktionen verborgen. Diese Komponente kann prinzipiell in jeder Art von Applikation verwendet werden, die unter dem Gesichtspunkt der Portabilit�t entwickelt wird.

\begin{table}
\begin{center}
\begin{tabular}{|ll|}
\hline
rtconsol & Funktionen f"ur Textausgabe auf der Konsole\\
rtcorout & Verwaltung von Coroutinen\\
rtdebug & Grundlegende Debugging-Unterst"utzung\\
rterror & Ausgabe von Fehlermeldungen auf STDERR\\
rtexcept & Ausnahmebehandlung\\
rtfile & Datei-Funktionen f"ur "Offnen, Schlie"sen, Ein- und Ausgabe\\
rtformat & Umwandlung von numerischen Werten in Zeichenketten f�r die Ausgabe\\
rthash & Unterst"utzung von Hash-Tabellen\\
rtmac & Macintosh-spezifische Funktionen und Ein- /Ausgabefenster\\
rtmemory & Speicherverwaltung\\
rtos & Betriebssystemabh"angige Funktionen\\
rtring & Funktionen f"ur Ringdatenstrukturen\\
rtscan & Umwandlung von Zeichenketten in numerische Werte\\
rtsess & Initialisierungen f"ur eine Tycoon-Sitzung\\
rtsl & Sonderfunktionen f�r Zeichenkettenliterale\\
rtstd & Basisdatentypen- und  Konstantendefinition\\
rtstream & Initialisierung von abstrakten Zeichenstr�men\\
rtstring & Funktionen f"ur das Kopieren, Vergleichen und Verketten von Zeichenketten \\ 
\hline
\end{tabular}
\end{center}
\caption{Die Dateien des Runtime-Systems}
\label{tableRT}
\end{table}

\subsection{Tycoon Virtual Machine}
\label{Tycoon-Machine}

Zentrales Element der Tycoon-Maschine ist der Byte-Code-Interpreter. Dar�ber hinaus gibt es weitere	Module, welche die Funktionalit�t der Byte-Codes implementieren. Das sind z.B. solche zur Transaktionsverwaltung, Multi-Threading, Store-Zugriffe und der Aufruf externer C-Funktionen (siehe Tabelle \ref{tableTM}).

\begin{table}
\begin{center}
\begin{tabular}{|ll|}
\hline
tm & Hauptroutine des Tycoon-Systems\\
tmaccess & Funktionen zum Registrieren von C-Funktionen\\
tmbyte & Definition der Tycoon Byte-Codes\\
tmccall & Funktionen f�r den Aufruf von  C-Funktionen aus Tycoon\\
tmdata & Abbildung von Tycoon- auf C-Datentypen\\
tmdebug & Unterst�tzung f�r Tycoon-Debbuging auf C-Ebene\\
tmdiss & Dissassembler\\
tmexcept & Ausnahmebehandlung\\
tmexec & Hauptschleife des Byte-Code-Interpreters\\
tmgc & Hilfsfunktionen f�r die Freispeicherverwaltung (Garbage Collection)\\
tmhash & Funktionen f�r Tycoon Hash-Tabellen\\
tmlink & Funktionen f�r das Binden von  C-Funktionen aus Tycoon\\
tmmeta & Werte f"ur das dynamische Binden von Tycoon-Funktionen\\
tmprint & Formatierte Ausgabe von Tycoon Speicherobjekten\\
tmrecord & Implementation von Tycoon Tupeln (Records)\\
tmset & Implementation von Tycoon Mengen (Sets)\\
tmstatic & Registrierung statisch gebundener C-Funktionen\\
tmstore & Hilfsfunktionen f�r die Objektspeicherverwaltung\\ 
tmthread & Unterst�tzung von Tycoon-Threads\\ 
tmtrans & Transaktionsverwaltung\\ 
\hline
\end{tabular}
\end{center}
\caption{Die Dateien der Tycoon Virtual Machine}
\label{tableTM}
\end{table}


\subsection{Unterst"utzung von TL-Befehlen}
\label{Unterstuetzung von TL-Befehlen}

Die Sprache TL bietet einige Funktionen, die nicht direkt durch den TVM-Byte-Code abgedeckt werden k�nnen. Es handelt sich dabei z.B. um erweiterte Thread-Funktionalit�t, C-Callbacks, dynamisches Binden von TL-Funktionen usw. Die entsprechenden Funktionen sind daher in C realisiert und werden in TL eingebunden. Die Module f�r diese Erweiterung der Basisfunktionalit�t bilden die dritte Komponente der Tycoon Maschine (siehe Tabelle \ref{tableTL}).

\begin{table}
\begin{center}
\begin{tabular}{|ll|}
\hline
tlatom & Symbole f"ur dynamisches Linken\\
tlcback & Aufruf von Tycoon aus C (C-Callbacks)\\
tlreader & Eingabe �ber Dateien (nicht blockierend)\\
tlreal & Flie�kommaoperationen\\
tlsymbol & Unterst�tzung f�r TooL-Symbole\\
tlsunrpc & Funktionen f�r Sun-RPC\\
tlthread & Komplexere Thread-Funktionen\\
tlunsafe & Typunsichere Funktionen\\
\hline
\end{tabular}
\end{center}
\caption{Die Dateien f"ur Tycoon-nahe Funktionen}
\label{tableTL}
\end{table}


\section{Funktionelle Einheiten}
\label{Funktionelle Einheiten}

H"aufig bilden Module aus mehreren Komponenten eine funktionelle Einheit. Die wichtigsten dieser Einheiten werden im folgenden vorgestellt und das Zusammenspiel der Module untereinander erl"autert.

\subsection{Ein-/Ausgabe}
\label{Ein-/Ausgabe}

Die Ein- und Ausgabe von Daten "uber Tastatur, Bildschirm, Dateien oder andere Rechner erfolgt einheitlich "uber sogenannte Streams. Das Konzept derartiger Daten- bzw. Zeichenstr"ome wird bereits durch die Sprache C bereitgestellt: das "Offnen einer Datei z.B. liefert einen Stream, der anstelle des Dateinamens in weiteren Operationen auf dieser Datei verwendet wird. Ein Stream hat bestimmte Eigenschaften, die zur Zeit seiner Erzeugung festgelegt werden. F"ur eine Datei kann z.B. ein Datenstrom ge"offnet werden, der nur Lesezugriffe zul"a"st.

Aus technischer Sicht wird ein Stream in der Sprache C durch eine Datenstruktur realisiert, die unter anderem aus einem Datenpuffer und einem Zeiger in diesen Puffer besteht. Eine Leseoperation z.B. f"ullt diesen Puffer mit Daten aus der zugeordneten Datei und setzt den Zeiger auf die resultierende neue Position. In Funktionsaufrufen wird der Stream-Parameter in Form eines Zeigers auf die entsprechende Datenstruktur "ubergeben. Es existieren in C drei Standard-Streams, die nicht explizit ge"offnet bzw. angelegt werden m"ussen \cite{KeRi77}. Sie werden durch drei benannte Konstanten repr�sentiert, die anstelle eines Zeigers "ubergeben werden k"onnen. Es sind dies {\sf ``STDIN''} oder der Wert 0 f"ur Eingaben von der Konsole (Tastatur), {\sf ``STDOUT''} (1) f"ur Ausgaben auf die Konsole (Bildschirm) und {\sf ``STDERR''} (2) f"ur Fehlerausgaben.

In Tycoon wurde das Konzept der Streams verallgemeinert, um die Verwendung selbstentwickelter Stream-Typen zu erm"oglichen. Ein Stream wird ebenfalls durch eine Datenstruktur realisiert (siehe Abbildung \ref{sourcertstream}). Diese enth"alt neben dem Zeiger auf die Datenstruktur des C-Streams weitere Angaben, aus denen dessen Eigenschaften ersichtlich und somit �ber den Zeitpunkt seiner Generierung hinaus bekannt sind. Zus�tzlich werden in diese Struktur Funktionszeiger auf Operationen eingetragen, die f"ur den jeweiligen Stream zul"assig sind.

\begin{figure}
\begin{verbatim}
typedef struct rtstream_T {
  void *hDefault, *hOut, *hIn;
  void (*close)(struct rtstream_T *stream);
  void (*flush)(struct rtstream_T *stream);
  void (*clear)(struct rtstream_T *stream);
  Word (*write)(struct rtstream_T *stream, void *pBuffer, Word nBytes);
  void (*put)(struct rtstream_T *stream, Byte b);
  void (*putString)(struct rtstream_T *stream, String s);
  void (*putEndOfLine)(struct rtstream_T *stream);
  Word (*ready)(struct rtstream_T *stream);
  Word (*read)(struct rtstream_T *stream, void *pBuffer, Word nBytes);
  Bool (*get)(struct rtstream_T *stream, Byte *b);
  Bool (*getLine)(struct rtstream_T *stream, String sLine, Word nMaxChars);
  void (*setPosition)(struct rtstream_T *stream, Word iPosition);
  Word (*position)(struct rtstream_T *stream);
  Bool (*endOfStream)(struct rtstream_T *stream);
  Word (*nBytes)(struct rtstream_T *stream);
  Bool fAllocated, fWrite, fRead, fPosition, fLine;
} rtstream_TStruct, *rtstream_T;
\end{verbatim}
\caption{Die Tycoon Stream-Datenstruktur}
\label{sourcertstream}
\end{figure}

Ein-/Ausgaben "uber die Konsole, Dateien und Fehlerausgaben k"onnen jeweils als Spezialf"alle von Stream-Operationen angesehen werden. Dies f"uhrt zu einer Aufteilung der Funktionen auf vier Module: {\sf ``rtstream''} (Stream-Operationen), {\sf ``rtfile''} (Dateioperationen), {\sf ``rtconsole''} (Konsole) und {\sf ``rterror''} (Fehlerausgaben). Das Modul {\sf ``rtstream''} enth"alt die grundlegenden Funktionen f"ur das Anlegen und L"oschen eines Streams. Die "ubrigen Module stellen die jeweils zul�ssigen Funktionen f"ur Ein-/Ausgabeoperationen zur Verf"ugung, die in der Tycoon-Datenstruktur eingetragen werden. F"ur die Konsole wird nur ein Tycoon-Stream ge"offnet, der {\sf ``STDIN''} und {\sf ``STDOUT''} zusammenfa"st. Dies geschieht in der Startphase der Applikation, auf die sp"ater n"aher eingegangen wird.

Derzeit werden f�r alle Arten von Streams die zul"assigen Ein-/Ausgabeoperationen "uber die Funktion {\sf ``rtfile\_initStream''} in die Stream-Datenstruktur eingetragen, unabh"angig davon, ob es sich um den Konsole-, Fehler- oder einen Datei-Stream handelt. Dies scheint f"ur viele Betriebssysteme und insbesondere Unix vertretbar, da die Lese- und Schreiboperationen auf allen Stream-Typen gleiche Funktionalit"at bieten.  Trifft dies f"ur ein bestimmtes Betriebssystem nicht zu, k"onnen diese Initalisierungen "uber unterschiedliche Funktionen vorgenommen werden.

\subsection{C-Calls}
\label{C-Calls}

Ein betr"achtlicher Anteil an Funktionalit"at in der Sprache Tycoon wird "uber den Aufruf externer C-Funktionen bereitgestellt \cite{Matt93}. Der Aufruf solcher Funktionen bleibt f"ur den Anwender v"ollig transparent: ein entsprechender Befehl in der Hochsprache TL bindet einen Tycoon-Bezeichner an eine C-Funktion. Der tats"achliche Aufruf einer C-Funktion wird "uber einen TVM-Code realisiert, der die notwendigen Umsetzungen ausl"ost.

Der Aufruf einer C-Funktion setzt sich aus drei Schritten zusammen: der Konvertierung der Parameter von Tycoon- in C-Format, dem eigentlichen Aufruf der Funktion und der Umwandlung des Ergebnisses in einen Tycoon-Datentyp.  Die Funktionen f"ur Typkonvertierungen sind im Modul {\sf ``tmdata''} zusammengefa"st. Die Liste der Tycoon-Parameter wird schrittweise abgearbeitet und das Ergebnis jeder Konvertierung in ein C-Array f"ur maximal 20 Parameter eingetragen. Die C-Funktion wird dann "uber ihren Funktionszeiger aufgerufen. Die Parameterliste setzt sich aus den Feldern des genannten Arrays zusammen. Aufgrund der Aufrufkonventionen in C werden die Parameter derart auf dem Stack abgelegt, da"s eventuell "uberfl"ussige Argumente die Ausf"uhrung nicht beeintr"achtigen. Nach R"uckkehr der Funktion wird das Ergebnis in ein Tycoon Datenformat gewandelt.

Eine besondere Technik wurde f"ur die Ermittlung der Funktionszeiger gew"ahlt, wobei statisch und dynamisch gebundene Funktionen unterst"utzt werden. In der Startphase der Tycoon-Applikation werden alle statisch gebundenen Funktionen in einer Hash-Tabelle erfa"st. Zum Zeitpunkt des C-Funktionsaufrufes wird diese Hash-Tabelle durchsucht und im Erfolgsfall der so ermittelte Zeiger verwendet. Scheitert die Suche, so wird "uber betriebssystemspezifische Operationen versucht, die Funktion dynamisch zu binden. Bleibt auch dies Vorgehen erfolglos, so wird die Ausf"uhrung des Tycoon-Programmes mit einer entsprechenden Fehlermeldung abgebrochen.

Die Funktionalit"at f"ur C-Aufrufe ist auf die Module {\sf ``tmccall''}, {\sf ``tmaccess''}, {\sf ``tmlink''} und {\sf ``tmstatic''} verteilt. Die Datei {\sf ``tmstatic''} besteht lediglich aus der Funktion {\sf ``tmaccess\_begin''}. Sie enth"alt f"ur jede statisch zu bindende Funktion eine Makro-Anweisung, die zu einer Registrierung in der Hash-Tabelle expandiert wird. Der Hash-Algorithmus verwendet als Schl"ussel eine Kombination aus dem Funktionsnamen und dessen L"ange. Der Aufbau der Tabelle l"auft in zwei Schritten ab. Zun"achst wird die L"ange jedes Funktionsnamens ermittelt und so die Gesamtgr"o"se des Speicherbereiches bestimmt, in dem die Schl"ussel der Tabelle abgelegt werden. Im zweiten Durchlauf werden dann die Schl"ussel und Funktionszeiger tats"achlich in die Hash-Tabelle eingetragen.

Die Datei {\sf ``tmlink''} enth"alt betriebssystemabh"angige Implementationen f"ur den Bindevorgang, da sich die Funktionsweise des dynamischen Bindens auf den verschiedenen Plattformen sehr unterschiedlich darstellt. Die Umsetzung eines Tycoon-Bezeichners in einen Funktionsnamen und gegebenenfalls einen Bibliotheksnamen wird durch Funktionen in dem Modul {\sf ``tmaccess''} gew"ahrleistet.

\subsection{Das abstrakte Objektspeicherprotokoll TSP}
\label{TSP}

Das {\sf ``Tycoon Store Protocol''} ({\sf TSP}) ist eine weitgehend modellunabh�ngige Objektspeicherschnittstelle \cite{Matt93}. Es definiert abstrakte Funktionen f�r das Anlegen, Lesen und Modifizieren von Objekten. Das Tycoon-System kann auf unterschiedlichen Objektspeichern operieren, da es lediglich �ber Funktionen des TSP auf den Objektspeicher zugreift. Die Funktionen des TSP m�ssen dazu auf solche des Objektspeichers abgebildet werden. 

Der DBIS-eigene Objektspeicher ({\sf TY}coon {\sf MEM}ory) implementiert alle notwendigen Funktionen, ein Mehrbenutzerobjektspeicher ({\sf TYSIN}) ist ebenfalls verf�gbar. Die Definitionen der abstrakten Funktionen befinden sich in der Datei {\sf ``tsp.h''}, im Falle der Verwendung eines Objektspeichers eines Drittanbieters mu� lediglich ein zus�tzliches Modul eingef�gt werden.

Das TSP umfa�t insbesondere Mechanismen f�r die Unterst�tzung datenintensiver Anwendungen. Dies sind:
\begin{description}
\item [Automatische Freispeicherverwaltung] Objekte k�nnen nicht explizit gel�scht werden, sondern sie werden durch eine Garbage Collection beseitigt, sobald sie nicht mehr erreichbar sind.
\item [Persistenz] Alle von einem persistenten Wurzelobjekt erreichbaren Objekte sind ebenfalls persistent.
\item [Atomarit�t, Fehlererholung] Es gibt Sicherungspunkte (Commit) und R�cksetzoperationen (Rollback), die atomare Zustands�berg�nge gew�hrleisten.
\item [Portabilit�t] Das TSP erm�glicht den Austausch von Daten zwischen verschiedenen Hard- und Softwarearchitekturen. Der Objektspeicher bleibt f�r Wertkonvertierungen verantwortlich.
\item [Synchronisation] Das TSP bietet Synchronisationmechanismen, um Mehrbenutzerbetrieb zu erm�glichen.
\end{description}

Das TSP verwaltet Objekte beliebiger Gr��e, die Objektgr��e wird zum Zeitpunkt der Objektgenerierung festgelegt. Es wird eine markierte Datenrepr�sentation (tagged format) verwendet, um die Freispeicherverwaltung und den Datenaustausch zu erleichtern.

Das TSP bietet Funktionen f�r unterschiedliche Aufgaben: Ermittlung der Eigenschaften des darunterliegenden Objektspeichers, Operationen auf Objekten, Operationen f�r Objektspeicher, Transaktionsoperationen, Freispeicherverwaltung und solche f�r den Datenim- und export.

\subsection{Threads und Coroutinen}
\label{Threads und Coroutinen}

Der Einsatz von Multi-Threading erlaubt eine quasiparallele Ausf"uhrung mehrerer Programme auf einem Prozessor, im Falle von Tycoon auf der gleichen virtuellen Maschine \cite{MMS95}. Threads werden als ``leichtgewichtige Prozesse'' (lightweight processes) bezeichnet. Es existieren mehrere Threads innerhalb eines Betriebssystemprozesses, wobei in jedem Thread eigenst"andiger Programmcode ausgef"uhrt wird. Die Threads eines Prozesses teilen sich Resourcen wie offene Dateien, Kommunikationskan�le oder den Objektspeicher 
\cite{DBBB95}.

Ein Thread stellt einen Punkt im Kontrollflu"s eines Programmes dar. In Multi-Threading-Systemen gibt es daher zu einem Zeitpunkt mehrere Programmcodeteile in Ausf"uhrung;

Ein Thread im Tycoon-System ist eine Instanz eines abstraktenTycoon-Datentyps. Dieser umfa�t den auszuf�hrenden Programmcode, den Kontext der ausf�hrenden virtuellen Maschine wie ``stack'', ``stack pointer'', ``instruction pointer'', ``frame pointer'' usw. und Referenzen auf andere Objekte. Ein Thread und somit ein Tycoon-Programm in Ausf�hrung kann angehalten, auf ein anderes Tycoon-System �bertragen und dort zu einem beliebigen Zeitpunkt fortgesetzt werden.

Die grundlegenden Funktionen f�r die Verwaltung von Threads wie deren Erzeugung, Anhalten, Fortsetzen etc. sind im Modul {\sf ``tmthread''} untergebracht. Es gibt weitere Funktionen, die f�r die Erweiterung der Tycoon Language ben�tigt werden. Sie befinden sich im Modul {\sf ``tlthread''} und es sind zumeist Operationen f�r die koordinierte Ausf�hrung von Threads.

Die Kontextinformationen eines Threads werden zur Ausf�hrung in eine C-Datenstruktur �bertragen. Das Multi-Threading wird durch Coroutinen \cite{Marl80} implementiert: f�r jeden Thread wird eine Coroutine instanziiert, die einen Byte-Code-Interpreter ausf�hrt. Dieser arbeitet den jeweils zugeordneten Thread ab. Die Ausf�hrungsreihenfolge der Coroutinen wird �ber eine ringf�rmige Zeigerdatenstruktur verwaltet: jede Coroutine zeigt auf ihren Vorg�nger und Nachfolger (siehe Abbildung \ref{sourcertring}). Ist lediglich der Tycoon Top-Level aktiv, der interaktive Befehlseingaben verarbeitet, so befindet sich lediglich eine Coroutine im Ring. Die Funktionen f�r Coroutinen befinden sich im Modul {\sf ``rtcorout''}, die zur Verwaltung von Ringstrukturen im Modul {\sf ``rtring''}. Die Abbildung \ref{sourcertcorout} zeigt die Datenstruktur einer Tycoon-Coroutine.

\begin{figure}
\begin{verbatim}
typedef struct rtring_T {
  struct rtring_T *ringPrevious;
  struct rtring_T *ringNext;
} rtring_TStruct, *rtring_T;
\end{verbatim}
\caption{Ring-Datenstruktur f�r die Verwaltung von Coroutinen}
\label{sourcertring}
\end{figure}

\begin{figure}
\begin{verbatim}
typedef struct {
  rtring_T ringPrevious;
  rtring_T ringNext;
  jmp_buf context;
  void *stack;
  void (*execute)(void);
  void *rtexcept_tag;
  void *rtexcept_parameter;
  void *rtexcept_pTarget;
  Bool rtexcept_fUnhandled;
} rtcorout_TStruct, *rtcorout_T;
\end{verbatim}
\caption{Coroutinen-Datenstruktur}
\label{sourcertcorout}
\end{figure}

\subsection{Speicherverwaltung ``Tycoon Virtual Machine''}
\label{Speicherverwaltung TVM}

Die Speicherverwaltung stellt einen potentiellen Problembereich bei der Portierung einer Applikation dar. Entsprechende Funktionen sind daher in der Datei {\sf ``rtmemory''} zusammengefa"st. Es existieren neben solchen f"ur das Allozieren und Freigeben von Speicher auf dem Heap noch weitere f"ur den Vergleich, das Ausdehnen und Kopieren von Speicherbereichen. Insbesondere gibt es Funktionen f"ur die Speicherallokation, die im Fehlerfall eine Ausnahmebehandlung ausl"osen.

S�mtliche Module der ``Tycoon Virtual Machine'' setzen auf den Speicheroperationen in {\sf ``rtmemory''} auf. Diese Kapselung f�hrt zu einer zentralen Speicherverwaltung. In anderen Funktionsbereichen wird die implizite Allokation von Speicher z.B. durch Funktionen aus Standardbibliotheken wie {\sf ``printf''} weitgehend vermieden. 

\subsection{Ausnahmebehandlung}
\label{Exceptions}

Die Module {\sf ``rtexcept''} und {\sf ``tmexcept''} stellen eine Reihe von Makros und Funktionen zur Verf"ugung, die eine rudiment"are Ausnahmebehandlung erm"oglichen. Dazu wird ein Anweisungsblock, dessen Ausf"uhrung zu Fehlern f"uhren kann, durch die Makros {\sf ``tmexcept\_TRY''} und {\sf ``tmexcept\_END''} eingeschlossen. In diesem Block kann mit dem Makro {\sf ``tmexcept\_WHEN''} auf einen bestimmten, mit {\sf ``tmexcept\_ELSE''} auf beliebige Fehler gepr"uft werden.

Die Makros bedienen sich der C-Anweisungen {\sf ``setjmp''} und {\sf ``longjmp''}, um vor einem Programmabschnitt, in dem Fehler auftreten k"onnen, den Prozessorkontex zu sichern. Dieser kann bei Mi�erfolg rekonstruiert und eine entsprechende Fehlerbehandlung vorgenommen werden. Insbesondere k�nnen Ausnahmepakete propagiert werden, die die Art der Ausnahme anzeigen.


\section{Die Startphase}
\label{Abs. Die Startphase}

\begin{figure}
\psbild{0.6#1}{.}{start.epsf}
\caption{Die Startphase des Tycoon-Systems}
\label{picStart}
\end{figure}

Die Tycoon-Hauptroutine {\sf ``tm\_main''} befindet sich im Modul {\sf ``tm''}. Die Abbildung \ref{picStart} zeigt die Schritte bei deren Bearbeitung. Sie er�ffnet durch den Aufruf der Funktion {\sf ``rtsess\_new''} (siehe Abbildung \ref{sourcertsess}) eine Tycoon-Sitzung. Diese Funktion nimmt die Initialsierung einer Vielzahl von Modulen vor. Bei den Initialisierungen handelt es sich meist um das L�schen oder Vorbelegen von Datenstrukturen. Die entsprechenden Operationen befinden sich jeweils in der Funktion {\sf $<$Modul$>$\_begin} eines Moduls. 

Die Funktion {\sf ``rtcorout\_begin''} erzeugt eine Coroutine {\sf ``Super''}. Sie �bernimmt die Freispeicherverwaltung (garbage collection) und die Kontrolle, sobald sich im sp�teren Verlauf des Programms keine Coroutinen mehr im Ring befinden. Sie l�st ggf. die Beendigung der Tycoon-Sitzung aus.

\begin{figure}
\begin{verbatim}
Bool rtsess_new(void)
{
  rtos_begin();
  if (!rtcorout_begin()) return FALSE;
  rtdebug_setAssertHandler(assertHandler);
  rtexcept_TRY
  {
    rterror_begin();
    rtconsol_begin();
    tsp_init();
    tmthread_begin();
    tmbyte_begin();
    tmaccess_begin();
#  ifdef tmstatic_STARVIEW
      svaccess_begin();
#  endif
    tmlink_begin();
    tmdebug_begin();
    tlcback_begin();
    tlsymbol_begin();
    toolrt_begin();
  }
  rtexcept_ELSE
    return FALSE;
  rtexcept_END;
  return TRUE;
}
\end{verbatim}
\caption{Die Funktion rtsess\_new}
\label{sourcertsess}
\end{figure}

Im Anschlu� daran wird die Kommandozeile gescannt, um den Namen des zu verwendenden Objektspeichers zu bestimmen und festzustellen, ob dieser ge�ffnet oder neu angelegt werden soll. Nach dem �ffnen oder Anlegen des Objektspeichers wird die Store-Software initialisiert. Im Falle eines Wiederanlaufens eines bestehenden Stores wird der Zustand zum Zeitpunkt des 
letzten Kontrollpunktes durch die Funktion {\sf ``tmtrans\_restart''} wiederhergestellt. Insbesondere werden alle aktiven Threads instanziiert. F�r einen neuen Store wird neben dem Thread {\sf ``Super''} lediglich ein weiterer Thread gestartet und mit der Funktion {\sf ``tmstore\_fileIntern''} das entsprechende Tycoon Boot-File in den Store geladen.

Schlie�lich wird die Funktion {\sf ``rtcorout\_ring''} aufgerufen, damit die Kontrolle an die Threads im Ring und somit an Tycoon Byte-Code-Interpreter abgegeben; das Tycoon-System ist aktiv.
