Eine Programmdatei besteht unter GEMDOS aus den folgenden Komponenten:
Der Header ist dabei wie folgt aufgebaut:
typedef struct { WORD ph_branch; /* Branch zum Anfang des Programms */ /* (muß 0x601a sein!) */ LONG ph_tlen; /* Länge des TEXT - Segments */ LONG ph_dlen; /* Länge des DATA - Segments */ LONG ph_blen; /* Länge des BSS - Segments */ LONG ph_slen; /* Länge der Symboltabelle */ LONG ph_res1; /* reserviert, sollte 0 sein */ /* wird von PureC benötigt */ LONG ph_prgflags; /* Programmflags */ WORD ph_absflag; /* 0 = Relozierungsinf. vorhanden */ } PH;
Eine Symboltabelle im Digital-Research-Format besteht aus jeweils 14 Bytes langen Einträgen, die aus dem Symbolnamen (maximal 8 Bytes; lediglich kürzere Namen sind mit einer 0 abgeschlossen!), einem 2 Bytes langen Symboltyp und dem eigentlichen Symbolwert (4 Bytes) bestehen. Die unterstützten Symboltypen sind in der folgenden Tabelle zusammengefaßt:
Wert | Symboltyp |
0x0100 | in der BSS |
0x0200 | im Programmtext |
0x0280 | Start eines Objektmoduls |
0x02c0 | Start einer Library |
0x0400 | im DATA-Bereich |
0x0800 | External |
0x1000 | Register |
0x2000 | Globales Symbol |
0x4000 | Equated |
0x8000 | Defined |
Viele Entwicklungssysteme (z.B. Pure-C) benutzen allerdings ein eigenes (i.d.R. leistungsfähigeres) Symbolformat. Da Programme unter TOS an eine beliebige Stelle des Arbeitsspeichers geladen werden können (und dort ablauffähig sein müssen), enthält eine Programmdatei normalerweise eine Relokationstabelle, mit deren Hilfe die im Programmcode angegebenen Adressen auf die tatsächlich zugewiesenen Bereiche umgerechnet werden können.
Ob Relokations-Informationen vorhanden sind oder nicht, kann der Komponente ph_absflag des Programmheaders (s.o.) entnommen werden. Es ist grundsätzlich nur eine Relozierung von 32-Bit-Werten (d.h. Adressen) möglich; vor GEMDOS-Version 0.15 (bzw. TOS-Version 1.04) durften die Relozierungsinformationen nur maximal 32 Kbyte umfassen.
Die Relokationstabelle selbst beginnt mit einem 32-Bit-Wert, welcher den Offset des ersten zu relozierenden Wertes relativ zum Beginn des Textsegmentes markiert. Für alle folgenden Offsets werden dann einzelne Bytes benutzt. Um auch Abstände größer als 255 korrekt handhaben zu können, wird dabei wie folgt verfahren: Wird als Offset eine 1 gefunden (dies ist aufgrund der Charakteristika der MC-680x0 Prozessorfamilie unmöglich), wird automatisch zum Offset der Wert 254 addiert. Für besonders große Abstände kann dieser Vorgang natürlich auch wiederholt werden. Eine leere Relokationstabelle wird übrigens durch einen Long-Wert von 0 gekennzeichnet.
Querverweis: Fcntl ARHEADER OHEADER OSHEADER PSETFLAGS Die Programmflags
Bei den Programmflags handelt es sich um einen Bitvektor innerhalb des Programmheaders, der wie folgt aufgebaut ist:
Bits | Bedeutung |
0 | Fastload-Flag. Wenn dieses Bit gesetzt ist, wird der Heap nicht gelöscht, sondern lediglich das BSS-Segment vorinitialisiert. |
1 | Wenn dieses Bit gesetzt ist, darf das Programm in das schnelle Alternate-RAM geladen werden. |
2 | Wenn dieses Bit gesetzt ist, dürfen Speicheranforderungen per Malloc aus dem Alternate-RAM bedient werden. |
3 | reserviert, sollte Null sein.
Wird für die Shared Library benutzt. |
4-7 | Speicherschutz-Modus |
8-11 | reserviert, sollte Null sein. |
12 | Shared-Text. Wenn dieses Bit gesetzt ist, darf das Text-Segment des Programms geshared werden. Wenn ein derartiges Programm beispielsweise 3-mal gestartet wird, dann existieren 3 verschiedene DATA- und BSS-Segmente, aber nur ein gemeinsames Text-Segment. Achtung: Das Bit sollte nur gesetzt werden, wenn das Programm keine absoluten Zugriffe auf das DATA- oder BSS-Segment durchführt. |
13-27 | reserviert, sollte Null sein. |
28-31 | TPA-Größenfeld. Hier kann in Schritten zu 128 Kbyte festgelegt werden, wieviel Speicher aus dem Alternate-RAM dem Programm maximal zugeteilt werden soll, wenn der Rechner über mehr ST-RAM als Alternate-RAM verfügt. Die 16 möglichen Werte stehen für Angaben zwischen 128 Kbyte und 2MByte. |
Querverweis: Programmheader Programmstart und TPA