Aufsteigen von Version 3.3

Leider ergibt sich durch die enorme Aufwertung des neuen Compilers für die Benutzer der alten Version 3.3 eine Menge Arbeit bei der Umstellung auf die Versionen ab 4.0. Die wichtigsten Unterschiede in Kürze:

• Compiler-Optionen haben nun eine andere Syntax. Alle Optionen in der alten Syntax müssen umgestellt werden!

  Die Option LongAlign ist nun stapelbar.

  Neu sind die Optionen EntryClear, CaseChk und NilChk.

• INLINE wurde durch den leistungsfähigeren Befehl ASSEMBLE ersetzt.

• Alle Prozeduren haben die Registerkonvention [#!RKMLib!#] zu befolgen. Dies betrifft nur alte INLINE-Prozeduren. Durchsuchen Sie auch Ihre Quelltexte nach nunmehr unnötigen SAVEREGS- und LOADREGS-Aufrufen!

• Das Register A4 wird nicht mehr innerhalb der Prozeduren neu geladen. Daraus ergeben sich einige wichtige Aspekte:

  Der Stackframe globaler Prozeduren ist anders, weil das Register A4 nicht mehr gerettet wird. Dadurch ändern sich auch die relativen Offsets der Parameter. Dies betrifft ebenfalls nur INLINE-Prozeduren.

  Alle Prozeduren, die dem Betriebssystem zur Verfügung gestellt werden -- also InputHandler, TrapHandler, ExceptionHandler, Prozeduren für RawDoFmt, Kollisionsprozeduren, und so fort -- müssen umgeschrieben werden. Eigene Subtasks und Prozesse müssen unter Umständen -- wenn sie Zugriff auf globale Variablen benötigen -- umgestellt werden. Nutzen Sie hierbei die Optionen ,,LoadA4`` und ,,SaveA4``!

• Exec.UByte und Exec.Byte wurden durch die neu vordefinierten Typen SHORTINT und SHORTCARD ersetzt. Ebenfalls neu ist der Typ SYSTEM.SHORTSET.

• Das Zeichen ,,\`` hat in konstanten Zeichenketten nun eine spezielle Bedeutung (siehe 5.1.6).

• Für Library-Moduln wird automatisch eine Objektdatei erzeugt.

• Libraries bestehen nun aus libraryD und libraryL. Libraries der Betriebssystemversion 2.0 gibt es zusätzlich als OptlibraryL, um bei vorsichtiger Versionsabfrage die neuen Möglichkeiten der Workbench 2.0 nutzen zu können, das Programm aber in eingeschränkter Weise auch unter 1.3 ablaufen zu lassen.

• Die Definition des Moduls Arts ist stark verändert. TermProcedures, DebugProcedures, DetectCtrlC und das Level-Konzept sind nicht mehr vorhanden. Sie wurden durch neue, leistungsfähigere Mechanismen ersetzt.

  Alle alten Moduln müssen angepasst und neu übersetzt werden!

  Statt der TermProcedures gibt es neu das ,,CLOSE``-Konzept (5.1.1).

  Für das Level-Konzept gibt es ein eigenes Modul ,,Call``.

  Für [C] und mehr existiert neu das Modul ,,Break``.

  Neu ist die Variable ,,Arts.programName``, die den Namen des eigenen Programmes sowohl beim Start vom CLI als auch von der Workbench zur Verfügung stellt.

• Das Modul Terminal wurde stark erweitert. Die Ausgaben werden nun gepuffert, was einen erheblichen Geschwindigkeitsgewinn mit sich bringt. Falls Ausgaben auf einer Zeile ,,stückweise`` erfolgen sollen, ist jeweils dazwischen nun ein Aufruf der Prozedur ,,Flush`` einzufügen, damit der Pufferinhalt ausgegeben wird. Dies geschieht sonst nur beim Zeilenvorschub, Pufferüberlauf, beim Aufruf von Lese-Prozeduren und am Programmende.

• Weder Arts noch Arguments arbeiten mit Dos.DupLock(). Ein Anwender darf nur noch die Locks freigeben, die er selbst erzeugt hat. Ein anderes Verhalten der beiden Moduln hat in der Vergangenheit zu vielen Problemen geführt. Bei der Umstellung ist besondere Vorsicht geboten. Der Programmierer ist für die Freigabe der erzeugten Locks selbst verantwortlich; dafür existiert als Hilfe nun das Modul ,,DosSupport``.

• Wegen des hochoptimierenden Linkers sind nun wieder sehr grosse Moduln mit vielen Prozeduren vertretbar. Von einigen Programmierern wurden Definitionsmoduln auf den nicht-optimierenden Linker der Version 3.3 zugeschnitten und somit ,,künstlich`` kleinere Teilmoduln geschaffen, die eigentlich (aus struktureller Sicht) zusammengehören. Man sollte seine eigenen Definitionsmoduln daraufhin durchsehen!