Objektdatei

Die folgenden Informationen zum Objekt-Format sind für den ,,normalen`` -Programmierer wahrscheinlich von geringer Bedeutung. Für Programmierer jedoch, die -fremde Daten oder Prozeduren in ein Programm einbinden oder -Teile in fremden Sprachen benutzen wollen, sind diese Informationen unerlässlich.

Der Compiler erzeugt Objektfiles, die dem neuen Amiga-Standard entsprechen. Dieses Format soll hier nicht vollständig erklärt werden, eine gute Beschreibung befindet sich in [#!AmigaDOS!#]. Wir wollen lediglich die M2Amiga-spezifischen Besonderheiten aufzeigen.

Jede Objekt-Datei besteht aus einer sogenannten Unit (Einheit), die beliebig viele Hunks enthält. Die Unit definiert einen internen Namen, der im -System immer identisch mit dem Namen des Moduls ist.

Für jede globale Prozedur (Level 0), jedes zum Hauptmodul lokale Modul und für das Hauptmodul selbst wird ein eigener Hunk erzeugt.

Jeder Hunk besteht aus einer Kennung, die den Typ festlegt, einem Namen, den eigentlichen Daten und eventuell weiteren Informationen, die Relokationen, externe Referenzen oder externe Definitionen beschreiben.

Es gibt neun verschiedene Hunktypen, welche die Art der Daten und den Typ des Speichers bestimmen, in dem sie beim Programmlauf abgelegt sind:

CODE

enthält die ausführbaren Maschinenbefehle oder auch Daten, die während des Programmlaufes nicht verändert werden. Der Typ des Speichers ist hier nicht festgelegt. Der Compiler erzeugt CODE-Hunks für die Prozeduren und die konstanten Zeichenketten.

CHIPCODE

ist das gleiche wie CODE. Hunks dieses Typs werden aber im Gegensatz zu CODE immer im CHIP-Speicher des Amiga abgelegt. Auf diesen Speicher haben neben der CPU auch die Custom-Chips Zugriff. Grafik- oder Musikdaten liegen bei diesem Hunktyp gleich beim Programmstart im Chip-Speicher, wodurch man sich ein späteres Umkopieren in diesen Speicher erspart. Der Compiler erzeugt für alle Prozeduren und konstanten Zeichenketten eines Moduls CHIPCODE-Hunks, wenn die Compiler-Option ,,ChipCode:=TRUE`` gesetzt wurde.

DATA

sind Daten, die gleich beim Programmstart mit Werten belegt sind, aber im Gegensatz zu CODE während des Programmlaufes verändert werden dürfen. Der Compiler erzeugt keine DATA-Hunks, sie können jedoch mit Hilfe eines fremden Compilers oder Assemblers erstellt und vom Linker in das Programm eingebunden werden. Näheres hierzu erfahren Sie im Abschnitt ,,Externe Variablen`` (5.1.12).

CHIPDATA

sind initialisierte Daten, die gleich beim Programmstart im Chip-Speicher liegen.

BSS

sind Daten, die zu Beginn des Programmlaufs immer mit dem Wert Null gefüllt sind und verändert werden dürfen. Der Compiler erzeugt einen BSS-Hunk für die globalen Variablen des Moduls.

CHIPBSS

werden im Chip-Speicher angelegt und mit Nullen gefüllt. Der Compiler erzeugt einen CHIPBSS-Hunk, wenn die Compiler-Option ,,ChipBSS:=TRUE`` im Quelltext angegeben wurde.

Der Vollständigkeit halber seien noch die Hunktypen FASTCODE, FASTDATA und FASTBSS erwähnt. Für diese Typen wird jeweils Fast-Speicher angefordert. Das Betriebssystem wird aber auch ohne die Angabe ,,FAST`` immer Fast-Memory zur Verfügung stellen, da dieser normalerweise die höchste Priorität hat. Im Fast-Memory laufen Programme schneller, aber ein Programm, das explizit Fast-Memory anfordert, wird auf einem Amiga ohne diese Art Speicher nicht ablauffähig sein! Deshalb werden diese Hunktypen vom Compiler nicht unterstützt. Der Linker kann sie aber ohne weiteres verarbeiten.

Der Name eines Hunks ist nur für den Linker wichtig. Er versucht, Hunks gleichen Namens zusammenzulegen bzw. Hunks mit unterschiedlichen Namen zu trennen. Der Compiler erzeugt genau 3 verschiedene Namen:

,,text``:

Alle CODE- und CHIPCODE-Hunks

,,``:

Einen leeren Namen haben BSS- und CHIPBSS-Hunks, die globale Variablen im -Modell enthalten.

,,__MERGED``

Dies für BSS- oder DATA-Hunks, die globale Variablen im -Modell enthalten. Diese erfahren durch den Linker eine besondere Behandlung, dass wir sogar von den Hunktypen ,,MERGBSS`` und ,,MERGDATA`` sprechen. Man beachte, dass hier CHIP...nicht möglich ist!

benutzt zwei neue Dinge, die im AmigaDos-Handbuch noch nicht aufgeführt sind und deshalb hier kurz erwähnt werden sollen:

• In hunk__ext gibt es den neuen Wert ext__dref16 (=134), der das -Modell und residente Programme erst möglich macht. Dies sind 16Bit Data-Referenzen auf die Basis der -Variablen des Moduls.
• Die Bedeutung von ext__ref16 ist erweitert worden. Nun ist es erlaubt, alle Prozeduren mit einem 16Bit-Offset anzuspringen, auch wenn sie in einem anderen Modul liegen. Genaueres kann im Abschnitt 2.6.5 nachgelesen werden.

Zum Abschluss eine Aufstellung der erzeugten Linker-Symbole und Hunks:

Tabelle 6.1: Linker-Symbole und Hunks

Typ	Symbol	Hunkname	Hunktyp
Exportierte Prozeduren	modul_Name	text	CODE
Interne Prozeduren	modul$nr	text	CODE
Lokale Moduln	(kein Symbol)	text	CODE
-Variablen	modul_VAR	__MERGED	BSS
-Variablen	modul_VAR	(ohne Namen)	BSS
Konstanten	modul_BY	text	CODE
Impmodul	modul_xxx...	text	CODE
...-CLOSE	modul_END
Librarymodul	modul_version	text	CODE
...-CLOSE	modul_END
Hauptmodul	__main	text	CODE
...-CLOSE	__mainEnd

Fast jeder Name setzt sich also aus dem Modulnamen, einem Unterstrich und einem bestimmten Bezeichner zusammen.