Für die COC (Checksum on Code) C-Library (entwickelt für Atari ST mit PureC) wurde auch ein Binding für PurePascal entworfen. Dies gelang aber schlussendlich nicht ganz zufriedenstellend. Unten sind einige der damals aufgetretenen Probeme festgehalten, hier ist die spez. Version von COC_PAS.C, die mittels #define PP eigentlich einen Objektcode erzeugen sollte, der dann in DEMO_COC.PAS eingebunden werden könnte.

Weitere Seiten: [ Up ] [ COC Artikel ] [ COC C-Source ] [ COC Pascal Binding ]

Probleme beim Einbinden von PureC Funktionen in ein Pure-Pascal Programm

Erkenntnisse aus einem Versuch mit SaPrSelfTest (COC)

Michael Vorburger, SG-CH (Juli 1993)

Folgende Probleme stellen sich (unter evtl. vielen anderen mehr...) bei der Verwendung von PureC (oder teilweise wahrscheinlich auch bei Objektdateien aus anderen Quellen) in PurePascal Programmen. Das grundsätzliche Vorgehen ist im Handbuch so erklärt:

Bei etwas komplexeren Routinen stellen sich aber Probleme en masse. Die mir bisher bekannten sind im folgenden zusammengefasst (mit Lösungsvorschlag).

Problem: Es müssen die Bibliotheksroutinen aus PureC müssen benutzt werden; gleichnamige aus PurePascal stürzen evtl. ab (besonders Ubergabe von Strings ist problematisch).

Lösung: Vor dem Einbinden der eigentlichen Funktion PC-Bibliotheken dazulinken (z.B. $L PCTOSLIB.LIB)

Problem: Funktionsdeklaration/Parameterübergabe: gerade NICHT mit pascal

Lösung: sondern "normal", d.h. cdecl

Problem: Zugriff auf Basepage geht nicht mehr über _BasPag (wie in PC)

Lösung: In PP geht's offiziell (gemäss Handbuch) anscheinend nicht, mit dem Debugger findet man aber eine Variable BASEPAGE, die ein Zeiger auf die Basepage des Programmes ist. Darauf kann aus PC nach der Deklaration extern struct baspag *BASEPAGE; wie auf _BasPag zugegriffen werden.

Problem: Ein grosses Problem ist auch, dass der in PurePascal integrierte Linker keine Objektmodule mit eigenem DATA- oder BSS-Segment akzeptiert.

Lösung: Erstmal können daher keine globalen Variablen verwendet werden. Das ist aber lange noch nicht alles; im Standard TOS.H werden einige Strukturen definiert, die ebenfalls Platz im Datensegment brau-chen würden. Am besten schreibt man daher eine eigene TOS.H, in der nur die wirklich benötigten Dinge drin sind (TOS_COC.H). Wenn man dann glaubt, das Datensegment müsse nun leer sein, kann die Fehlermeldung aber immer noch auftauchen. Nach langen Untersuchungen mit dem De-bugger stösst man dann darauf, dass die Zeile ULONG CurLongs[2] = {0,0}; acht Null-Bytes im Da-tabsegment ablegt. Mit der folgenden Formulierung geht's dann aber: ULONG CurLongs[2] ; CurLongs[0] = 0; CurLongs[1] = 0; Bei dieser Suche nach globalen Variabeln und Stellen, in de-nen diese benutzt werden, ist das Programm DISPOBJ.TTP übrigens von grossem Nutzen (gehört zum Lieferumfang von PC).

Problem: Für den Operator % (modulo) wird bei der Anwendung auf Longs (bei ints gibt's inline code) eine Bibliotheksroutine von irgendwo dazugelinkt, die PP nicht finden kann.

Lösung: % nicht benutzen; ersetzen durch: #define mod(x,y) (x - (x / y) * y)

Problem: Strings! PP und PC legen Strings verschieden ab (in Pascal- und C-Notation halt; mit Längenbyte oder mit #0-Terminator). Bei SaPrProgName führt das zu einem Problem, weil es im PP-Programm definiert wird, der Zugriff darauf aber in PC erfolgt.