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.
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.
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.