next up previous
Nächste Seite: Einbindung von C- und Aufwärts: Spezielles Linkverhalten Vorherige Seite: Hochoptimierender Linker

Kurze Sprünge

Wie im Abschnitt 6.1.1 auf Seite [*] angeschnitten, werden alle Prozeduren mit einem 16Bit-Offset angesprungen, auch wenn sie in fremden Moduln, gänzlich extern oder gar in CHIP-Hunks liegen. Dies spart eine Menge Code und beschleunigt Programme. Nun wird jeder, der den Amiga näher kennt, wissen, dass dies eigentlich unmöglich ist!2.30 Der Linker bemerkt diesen Umstand selbstverständlich und erzeugt bei Bedarf sogenannte ALVs (automatic link vector). Falls ein 16Bit-Sprung in einen anderen Hunk verweist, wird im eigenen Hunk ein absoluter Sprung auf das Ziel erzeugt und alle Sprünge darauf umgeleitet.


\begin{example}
Ruft nun eine Prozedur die Funktion {\tt Arts.Mulu32} auf und Ar...
...MP Arts_Mulu32anderer Hunk:
Arts_Mulu32:
...
RTS\end{verbatim}\end{example}

Hieraus wird auch ersichtlich, dass dies nur mit Sprüngen auf ,,normale`` Prozeduren funktionieren kann. Der Prozessor springt pc-relativ auf den ALV und von dort einfach weiter, was nur eine kurze Zeitverzögerung mit sich bringt. Falls jedoch eine Prozedur nur als ,,Verpackung`` für Daten dient und via ,,ADR`` angesprochen wird, kann diese Umleitung nicht klappen! Der Linker wird es aber nicht bemerken und brav seinen ALV generieren. Der Compiler weiss natürlich um diesen Umstand und verwendet eine entsprechende Adressierung. Wichtig wird es allerdings bei ASSEMBLE-Code. Es empfiehlt sich, innerhalb eines ASSEMBLE-Teils nur moduleigene Adressen relativ zu adressieren, modulfremde jedoch absolut.

Das gleiche gilt auch für Zeichenketten-Konstanten. Diese werden immer im gleichen Hunk wie der Code des zugehörigen Moduls untergebracht, können folglich vom eigenen Modul pc-relativ, von fremden Moduln hingegen nur absolut adressiert werden.


\begin{example}
Angenommen, man m\uml {o}chte nach obigen Beispiel das erste Wor...
....W (A0),D0
...
anderer Hunk:
Arts_Mulu32:
...
RTS\end{verbatim}\end{example}

Als zweite Lehre sollte man daraus ziehen, möglichst immer die Option ,,+c`` anzugeben bzw. die Standardeinstellung zu belassen, woraufhin soviel Code wie möglich in einen einzelnen Hunk gepackt, und die Erzeugung von ALVs unnötig wird. Da die meisten Programme kürzer als 32kByte sind, wird hierdurch ein sehr kompakter und schneller Code erreicht. CHIP-Code und ,,normaler`` Code können allerdings niemals in demselben Hunk untergebracht werden, wodurch ALVs erzwungen werden. Man sollte CHIP-Code also vermeiden.


next up previous
Nächste Seite: Einbindung von C- und Aufwärts: Spezielles Linkverhalten Vorherige Seite: Hochoptimierender Linker
Claudio Nieder 2000-11-12