% Studienarbeit von Markus Breilmann
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
% Kapitel 2: Aufbau des Tycoon-Systems, der Tycoon-Maschine und Abgrenzung gegen andere Architekturen


\chapter{Aufbau des Tycoon-Systems}
\label{Kap. Aufbau des Tycoon-Systems}

Die Entwicklung des Tycoon-Systems verfolgt eine Reihe von Zielsetzungen. Die Sprach\-umgebung soll die effiziente Programmierung datenintensiver Anwendungen, die Korrektheit von Programmen und geringen Wartungs- und Erweiterungsaufwand gew"ahrleisten. Dar"uber hinaus sollen vorhandene Software-Ressourcen wie Bibliotheken und externe Dienste genutzt werden k"onnen. Die Sprache soll dennoch leicht zu implementieren und portabel sein.

Tycoon verbindet Konzepte verschiedener Programmierparadigmen: es werden imperative, funktionale und objektorientierte Programmiertechniken unterst"utzt. Das System ist modular aufgebaut, verschiedene Arten der Polymorphie erlauben die Erstellung generischer Bibliotheken. Die Sprache ist strikt typisiert; es k"onnen sowohl statische als auch dynamische Typ"uberpr"ufungen durchgef"uhrt werden. Eine quasiparallele Ausf"uhrung von Programmen innerhalb eines Betriebssystemprozesses wird durch Multithreading erm"oglicht. Funktionen, Typen und Threads sind Sprachobjekte erster Klasse und k"onnen daher z.B. selbst als Funktionsargument auftreten. Alle Sprachobjekte wie Werte (Daten), Programmcode und Threads werden persistent in einem Objektspeicher gehalten.

Die zum Teil konkurrierenden Zielsetzungen und L"osungsans"atze erzwingen eine Systemarchitektur, die geeignet ist, die Komplexit"at nachhaltig zu reduzieren. Eine solche Architektur unterteilt das Gesamtsystem in mehrere funktionale Schichten. Jede dieser Schichten ist f"ur bestimmte Aufgabenbereiche optimiert. Das Tycoon Schichtenmodell wird in diesem Kapitel erl"autert und die Aufgaben der Komponenten dargestellt.

\section{Das Tycoon Schichtenmodell}
\label{Abs. Das Tycoon Schichtenmodell}

Die oberste Schicht des Tycoon-Systems stellt die eigentliche Programmiersprache zur Ver\-f"ugung und bildet somit die Schnittstelle zum Benutzer. Der grundlegende Ansatz der Schichtenmodellierung besteht darin, eine prinzipiell beliebige Hochsprache in den darunterliegenen Schichten auf Zwischenrepr"asentationen abzubilden, die f"ur bestimmte Aufgaben besonders geeignet sind. Derzeit sind zwei Hochsprachen implementiert: ``Tycoon Language'' (TL) und ``Tycoon object oriented Language'' (TooL). Sie k"onnen sowohl zur Applikationsentwicklung als auch zur Systemprogrammierung eingesetzt werden. Die TL-Sprachprozessoren selbst sind in TL realisiert. Der kleine Sprachkern kann dynamisch erweitert und durch Funktionen in Bibliotheken erg"anzt werden. Es handet sich bei TL um einen typisierten Lambdakalk"ul. In dieser Arbeit wird aus Gründen der Einfachheit lediglich auf die Sprache ``Tycoon Language'' Bezug genommen.

\begin{figure}
\psbild{0.5#1}{.}{TycoonSchicht.epsf}
\caption{Das Tycoon Schichtenmodell}
\label{picTycoonSchichten}
\end{figure}

Das Compiler Front-End wandelt Terme der Sprache TL in die Zwischenrepr"asentation {\sf ``Tycoon Machine Language''} (TML) um. TML ist eine nichtlineare Codierung im ``Continuation Passing Style'' (CPS). Ihre baumartige Struktur erlaubt Analysen und Optimierungen, wie sie aus Datenbanksystemen und anderen optimierenden Compilern bekannt sind. Der Sprachkern umfa"st lediglich wenige Instruktionen f"ur Funktionsdefinition und -applikation, destruktive Zuweisungen, bedingte oder wiederholte Auswertungen, Ausnahmebehandlungen und den Aufruf von Funktionsimplementationen externer Programmiersprachen.

Der TML-Code wird durch das Compiler Back-End in einen persistenten, portablen Byte-Code (Tycoon Virtual Machine, TVM-Code) umgewandelt, dessen Instruktionen an den Befehlssatz von Transputern angelehnt sind. Der Code ist von konkreten Hardware-Plattformen entkoppelt und umfa"st Operationen auf elementaren Tycoon-Datenstrukturen.

Der Tycoon Byte-Code wird durch die {\sf ``Tycoon Virtual Machine''} (TVM) ausgef"uhrt. Dieser virtuelle Computer bildet Operationen in Tycoon auf die jeweilige Hardware-Plattform ab.

Eine wichtige Rolle spielt das {\sf ``Tycoon Store Protokoll'' (TSP)}. Alle Datenstrukturen von atomaren Werten bis hin zu Programmcode und Threads werden in einem Objektspeicher gehalten. Dieser Objektspeicher kann ann"ahernd frei gew"ahlt werden; derzeit werden zwei Tycoon-eigene Stores, NapierStore und ObjectStore unterst"utzt. Das TSP bildet die Schnittstelle zwischen den Tycoon-Sprachen und diesen Objektpeichern: Operationen in h"oheren Schichten werden auf Objektkonstruktoren, -modifikatoren oder -destruktoren abgebildet. Dies entkoppelt die Sprache vollst"andig von konkreten Speichermodellen der zugrundeliegenden Hardware-Plattform. Das Problem der Freispeicherverwaltung, wie es z.B. durch Fragmentierung des Heap in klassischen Sprachmodellen entsteht, wird damit in Tycoon vermieden. Der jeweilige Objektspeicher ist f"ur eine effiziente Speicherverwaltung verantwortlich. Der Einsatz eines Objektspeichers erm"oglicht die Persistenz aller Tycoon-Objekte. Mit Hilfe von Sicherungspunkten (commit) und R"ucksetzmechanismen (rollback) kann f"ur das gesamte System Datenbankfunktionalit"at realisiert werden.

\section{Portabilit"at}
\label{Portabilitaet}

Das Tycoon-Schichtenmodell reduziert deutlich die Komplexität des Gesamtsystems. Ein Gro"steil der Funktionalität ist in den oberen Schichten angesiedelt und Sprachprozessoren, Type-Checker und weitere Module sind in TL selbst implementiert. Abhängig von der zugrundeliegenden Hardware und des Betriebssystems ist lediglich die Tycoon Maschine, die den persistenten Byte-Code ausführt. Ihre Aufgaben sind der Datenaustausch mit dem Benutzer, Modifikation des Objektspeichers, Aufruf externer Funktionen und einiges mehr. Der Anpassungsaufwand bei einer Portierung des Systems beschränkt sich also auf Funktionen in diesem Laufzeitsystem.

In der Literatur werden m"ogliche Problembereiche bei der Portierung aufgeführt und Empfehlungen für den Entwurf portabler Applikationen gegeben. Die folgende Aufstellung nennt die Punkte, die für das Tycoon-System relevant sind:

\begin{itemize}
\item Programmiersprache:
\begin{description}
\item [Sprachendialekt:] H"aufig implementieren Compiler eine Sprache in Bereichen unterschiedlich, in denen die Sprachdefinition L"ucken oder Unklarheiten l"a"st. In einigen F"allen gibt es sogar Abweichungen von Sprachstandard. Bietet eine Sprachimplementation gegen"uber dem Standard eine erweiterte Funktionalit"at, so sollte aus Gr"unden der Portabilit"at auf die Nutzung dieser zus"atzlichen Funktionen verzichtet werden \cite{Hend88}, \cite{Tane77}.
\item [Abbildung von Datentypen auf Speichereinheiten:] Datentypen k"onnen unab\-h"angig von der zugrundeliegenden Hardware unterschiedlich implementiert sein. Ein Integer kann z.B. 16 oder 32 Bit umfassen \cite{Tane77}, \cite{Wall82}.
\item [Packen von Daten:] Compiler k"onnen z.B. mehrere Bool'sche Variablen in einem Speicherwort ablegen. Der Datenaustausch mit anderen Plattformen wird dadurch unmöglich \cite{Schn80}, \cite{Tane77}. 
\end{description}
\item Flie"skommazahlen:
\begin{description}
\item [Zul"assiger Wertebereich:] Der Wertebereich f"ur die Darstellung von Flie"skommazahlen ist in hohem Ma"se von der zugrundeliegenden Hardware abh"angig \cite{Tane77}.
\item [Genauigkeit der Darstellung:] Die kleinste darstellbare positive Flie"skommazahl (h"aufig als Epsilon bezeichnet) ist ebenfalls maschinenabhängig. Dies f"uhrt z.B. bei Iterationen zu unterschiedlichen oder unbrauchbaren Ergebnissen, indem eine Reihe bis zu einem bestimmten Grenzwert konvergiert und danach divergiert. Eine unterschiedliche Genauigkeit bei der Berechnung des Grenzwertes f"uhrt dann zu abweichenden Ergebnissen \cite{Schn80}, \cite{Tane77}, \cite{Wall82}.
\end{description}
\item Dateien:
\begin{description}
\item [Dateinamen:] Die zul"assigen Zeichen, die maximale L"ange und der Aufbau von Dateinamen ist auf verschiedenen Betriebssystemen sehr unterschiedlich. PC's unter DOS und Windows limitieren Dateinamen z.B. auf 8 Zeichen plus 3 Zeichen Namenserweiterung \cite{Hend88}, \cite{Tane77}.
\item [Verzeichnisse und zugeh"orige Operationen:] F"ur den Aufbau von Dateisystemen existieren zahlreiche Ans"atze und es werden jeweils spezialisierte Operationen f"ur den Zugriff auf Dateien und Verzeichnisse ben"otigt \cite{Brow77}, \cite{Hend88}, \cite{Tane77}. 
\end{description}
\item interaktive Ein-/Ausgabe:
\begin{description}
\item [Behandlung der Ein-/Ausgabeeinheit:] In einigen Umgebungen wird die Ein- und Aus\-gabeeinheit wie eine Datei behandelt. Die zul"assigen Operationen sind in solchen F"allen h"aufig eingeschr"ankt \cite{Hend88}, \cite{Tane77}.
\item [Zeilenende:] F"ur die Markierung des Zeilenendes existieren vier M"oglichkeiten, CR, LF, CR+LF und LF+CR. Alle Kombinationen sind auf verschiedenen Systemen im Einsatz \cite{Tane77}.
\end{description}
\item Betriebssystem:
\begin{description}
\item [Speicherverwaltung und -zuteilung:] Manche Betriebssysteme weisen einem Programm bestimmte Speicherbereiche zu. In einigen F"allen werden Funktionen f"ur die Allokation von Speicher durch das Betriebssystem zu Verf"ugung gestellt \cite{Tane77}.
\item [Umgebungsvariablen, Systemzeit und -datum:] Die Verf"ugbarkeit von Systemzeit und -datum ist nicht auf allen Systemen sichergestellt und folgt zumindest unterschiedlichen Konzepten. Umgebungsvariablen existieren nur auf einigen Plattformen \cite{Schn80}, \cite{Tane77}.
\end{description}
\item Hardwareplattform:
\begin{description}
\item [Wortlänge:] Die Wortl"ange ist maschinenabh"angig und beeinflu"st u.a. die Darstellung von Integerwerten \cite{Brow77}, \cite{Schn80}, \cite{Tane77}.
\item [Addressierung:] Die Speicheraddressierung kann byte- oder wortweise erfolgen. Die Reihenfolge von Low- und High-Byte ist ebenfalls maschinenab"angig \cite{Schn80}, \cite{Tane77}.
\end{description}
\end{itemize}

Die 'Tycoon Virtual Machine' wurde in ANSI-C implementiert. Die Verwendung einer derart verbreiteten Standardsprache tr"agt in hohem Ma"se zur Portabilit"at des Systemes bei. Ein weiterer entscheidender Punkt ist die konsequente Modularisierung auf unterschiedlichen Ebenen, auf die sp"ater im Detail eingegangen wird. Sind m"ogliche Problembereiche bekannt, vereinfacht dieses Vorgehen die Kapselung aller kritischen Funktionen und damit Anpassungen. Der Einsatz von C-Präprozessorkommandos gestattet das selektive "Ubersetzen von maschinenabh"angigen Programmteilen.


