DOS-Forum

Es gibt irgend eine Einstellung bei Pascal (Compilerschalter), die einstellt, daß Units, die zusammen in ein "Segment" passen, so zusammen compiliert werden oder so. Mir selbst hat diese Einstellung nie Schwierigkeiten gemacht - aber vielleicht liegt es ja daran?
Ich selbst habe mit Pascal nie dergleichen Probleme gehabt wie hier geschildert - ich bin damit eigentlich sehr zufrieden. - Was natürlich nicht heißen soll, daß ich mir nicht vorstellen könnte, daß es solche Probleme geben kann.
(Ich programmiere ja selbst immer mit Pascal - und auch recht oft mit ASM-"Einschlüssen".)

Naja, ich hab noch ein paar Experimente gemacht und Routinen in Units ausgelagert bzw. ganz entfernt. Zum Beispiel habe ich jetzt eine Unit gebastelt, die als VAR einen Pointer besitzt, und im Initteil damit 40K RAM anfordert. Innerhalb der Procedure habe ich dann da eine BMP-Datei hineingeladen. Und natürlich zeige ich dieses Bild auch an - dazu verwende ich ASM - die Startposition im Segment A000 ist immer die gleiche - trotzdem befindet sich das Bild nach jedem Durchlauf an einer anderen Position... Ich verstehe das nicht, denn ich lade DI direkt mit einer Konstanten! Trotzdem kopiert REP MOVSW das Bild überall hin, nur nicht an die richtige Position.

Und auch da wieder - TPC meldet Fehler, IDE nicht...

Sooo... eine Neuigkeit gibt es - keine Ahnung warum, aber ich habe einfach aus Verzweiflung am Anfang ein {$M 16384,0,90000} eingefügt - und schwupps... jetzt gehts. Zwar zickt der Desktop ab und zu (offenbar bekommt das Programm falsche Variablen-Inhalte als Ergebnis von anderen Prozeduren - aber nur manchmal), aber es friert nichts mehr ein und bleibt nichts mehr hängen. Das ist ja schonmal was. Am Stack kanns ja nicht liegen - der ist doch glaub ich von Haus aus schon bei 16384?

Aber ja - ich habe Pascal besiegt!!! Lange hat es gedauert, aber ich triumphiere über den 486!

a)
Zum unterschiedlichen Verhalten von Command-Line-Compiler (tpc.exe) und in der IDE integrierten Compiler (tpx.exe):

Unterschiedliches Kompilierverhalten kann natürlich davon kommen, dass die Compilerschalter unterschiedlich sind. Der in der IDE integrierte Compiler verwendet die im Config-Menü der IDE eingestellten Compilerschalter. TPC.EXE hingegen die per Parameter übergebenen Compilerschalter.

Zum Gleichlauf kann man - wie schon mal geschrieben - durch zweimal <Strg-O> in der IDE die gerade aktuellen Compilerschalter in den Quelltext einfügen. Dann müßte auch TPC.EXE mit denselben Schaltern kompilieren.

Genaues kann ich allerdings nicht sagen, da ich mit TPC.EXE bei TP 7.0 noch nie gearbeitet habe. (Bei TP 5.0 und 6.0 war das anders: Dort war wegen der IDE oftmals der freie Speicher knapp, so dass man größere Programme immer extern kompilieren musste).


b)
Zu der komischen Parameterübergabe:

Ich kann mich gerade daran erinnern, dass ich einmal Probleme hatte, wenn ich Byte-Variablen als Procedure-Parameter übergeben hatte, diese Parameter aber als Integer definiert waren.

Grundsätzlich ist es meines Wissens so, dass der Compiler bei einer Bytezuweisung an eine Integervariable deren High-Anteil löscht. (Ich denke, dass das so ist. Mangels Retro-PC kann ich momentan nichts überprüfen!).

Wenn ich also
habe, sollte in MyInteger der Wert 25 stehen. (Wie gesagt, soweit ich mich erinnere. Ich kann das derzeit nicht nachprüfen). Ggf. muß auch der Compilerschalter für OPEN oder Extended Paramaters angeschaltet sein, da Pascal nach Wirth m.W. keine Zuweisungen verschiedener Typen erlaubt.


Ich dachte anfangs, das sei bei PROCEDURE - Parametern genauso.

Habe ich z.B. eine

und übergebe ich hier einen ByteVariable, z.B:
wird die Kopierschleife REP MOVSB aus der PROCEDURE Kopiere aber undefinierbar oft aufgerufen.

Grund dürfte sein: Pascal übergibt hier nur das Low-Byte (=MyByte) und trägt dieses in den Stack ein, muß aber ein ganzes Word für den Stack reservieren,um WieOft unterzubringen. Der High-Anteil von WieOft ist aber zufällig, wodurch sich für das CX bzw. die Variable WieOft ein zufälliger Wert ergibt.


Mittels TypeCasting (@Dosenware: mein Dauerliebling! Viel besser als absolute!) geht es aber ohne Probleme:
also Kopiere(p1, p2, Integer(MyByte) );


Wie gesagt: ohne Prüfung, frei nach Erinnerung.

PS: Du hattest doch mal HD-Probleme. Hattest Du schon mal probiert, TP auf eine andere Stelle komplett neu zu installieren? Ich hatte mal bei einer alterschwachen HD das Problem, dass Programme nicht mehr richtig funktionierten, auch wenn Scandisk keine Fehler gemeldet hatte. Neuinstallation auf einen anderen Bereich der Platte hatte damals geholfen, bis die HD ganz tot war.

Hallo Wobo!

Ich habe noch mal "Hand angelegt". Keine Fehler mehr im Kompilat. Warum auch immer. Ich habe auch schon an die HD gedacht - aber das Verhalten ist das selbe, wenn ich am Pentium I arbeite.

Das mit den Byte/Word/Integer kenne ich schon - darauf bin ich des öfteren reingefallen - auch ohne Assembler Da reicht schon:

var filesize: LongInt;
w1,w2,w3: Word;
begin
...w1 bis w3 mit irgendwas belegen...
FileSize:=w1+w2+w3;

end.

Edit:
Noch was zum Thema IDE/TPC: Die Compilerschalter füge ich immer in den Quellcode ein - so ist es noch unerklärlicher, warum TPC und IDE unterschiedliche Fehler ankreiden. Zumal einmal auch ein Schreibfehler von der IDE nicht erkannt wurde (vergleichbar mit Writlen; anstatt WriteLn;), von TPC aber schon.



Dann kommt FileSize nicht mehr über 65535 heraus. Wobei ich nie verstanden habe, wo da der Compiler seine Probleme hat, denn in ASM könnte man auch so vorgehen

MOV BX,irgendwas
ADD AX,BX
ADC DX,0 ; DX:AX=DX:AX+BX

Ähnlich dürfte doch normal der Compiler vorgehen - trotzdem setzt er FileSize auf Word-Größe.... Aber ich glaube, man muss TP nicht verstehen Man darf nur festhalten, dass Bytesparerei meistens mit Ärger verbunden ist, und "Geprasse" - wie im obigen Beispiel (statt 3 Words 3 LongInts definieren) besser ist

Es gibt zu dem o.g. Beispiel einen Trick, den ich selbst herausgefunden habe:
Wenn ein Ausdruck nur Integer-Werte (also shortint,byte,integer,word oder longint) enthält, dann wird der Zielvariablen immer ein Wert des Typs des ersten Wertes zugewiesen.
Beispiel: Man hat ein Byte, das einen Shift-Wert enthält:
var Ergebnis:Longint;
var wert,shiftwert:byte;
begin
shiftwert:=26;wert:=5;
Ergebnis:=wert shl shiftwert;
end.

Man erhielte das Ergebnis 0, weil Wert ein Byte ist.
Man kann aber die Wertbezeichnungen in Pascal auch wie eine Funktion verwenden, dann funktioniert es:

Ergebnis:=longint(wert) shl shiftwert;

Bei diesem Filesize-Beispiel ginge das:

statt FileSize:=w1+w2+w3;
einfach
FileSize:=longint(w1)+w2+w3;

So kann man z.B. auch 2er Potenzen auch bauen:
Ziel:=longint(1) shl shiftbyte;

Ließe man in diesem Fall das longint() weg, würde der Typ von shiftbyte benutzt werden - da 1 eine Konstante ist, hat sie quasi "keinen Typ".

Habe das mal irgendwann herausgefunden und verwende Dinge wie diese regelmäßig.
Wegen meiner vielen "Tricks" sehen meine Sourcen mittlerweile öfters mal etwas "crazy" aus. Aber für mich zählt, daß es funktioniert - nicht, daß der Source hübsch aussieht...

Das ist ein guter Trick Das muss ich mir merken. Vielen Dank.