Bedeutung von Compilerdirektiven $F, $K, $N und $S

[MaBuSE]

Hallo,

wenn ich im Delphi 7 [Strg+O] und nochmal O drücke, dann fügt Delphi mir die aktuell eingestellten Compilerdirektiven oben im Quelltext ein.

Die interessante Zeile ist:{$A8,B-,C+,D+,E-,F-,G+,H+,I+,J-,K-,L+,M-,N+,O+,P+,Q-,R-,S-,T+,U-,V+,W-,X+,Y+,Z1} Meine Frage ist nun:
Welche Bedeutung haben die Direktiven $F, $K, $N und $S ?

Die anderen Direktiven sind in der Hilfe beschrieben, die 4 oben leider nicht.

[Robert Marquardt]

Klapper mal die Hilfe zu den Compilerdirektiven sequentiell ab. Ein paar stehen nicht im Index.
Das kann sowieso nicht schaden, denn da lernt man interessante dinge.

[MaBuSE]

Zitat von Robert Marquardt:

Klapper mal die Hilfe zu den Compilerdirektiven sequentiell ab. Ein paar stehen nicht im Index.
Das kann sowieso nicht schaden, denn da lernt man interessante dinge.

Das habe ich schon
Trotzdem sind die 4 nicht dokumentiert. (jedenfals nicht in der Onlinehilfe)

[Brüggendiek]

Hallo MaBuSe!


Wieso sollte das nicht in der Hilfe stehen

Hier frisch aus der Online-Hilfe:

Code:

{$F+} / {F-}

Erzwingen von FAR-Aufrufen bei Unterprogrammen.

Code:

{$K+} / {KF-}

Smart Callbacks (für Callback-Funktionen).

Code:

{$N+} / {N-}

Numerischen Coprozessor (80x87) benutzen. Dazu gehört dann noch:

Code:

{$E+} / {E-}

Coprozessor ggf. über Hauptprozessor-Arithmetik emulieren (wird beim Programmstart festgestellt und dann werden Tabellen passend geschrieben).

Code:

{$S+} / {S-}

Stack-Prüfung - beu UP-Afrufen wird geprüft, ob noch Platz für die lokalen Variablen auf dem Stack ist.

Code:

{$S nnn}

Segmentgröße festlegen.


Achso - um das zu ermitteln, habe ich nicht das "Orakel von Delphi" gefragt, sondern "Im Namen der DOSe" meinen TURBO gezündet!
Es handelt sich um Optionen, die bei Turbo-Pascal 7.0 (oder auch schon früher) gültig waren und heute keine Bedeutung mehr haben. Deshalb sind sie ja auch nicht mehr dokumentiert.

Bei $E gibt es - wenigstens bei mir - inzwischen eine neue Bedeutung. Nach Deinem Post wird jedoch die alte Bedeutung ($E-) eingefügt.

Frag's Pferd - oder vielleicht die DP- - warum Delphi die Dinger immer noch mitschleppt.

Andererseits: Es wird ja sogar noch CP/M-Ballast mitgeschleppt! Die Routinen für Datenträger-Größe und freien Speicherplatz erwarten das Laufwerk als Zahl - wie bei CP/M geübt. Die Ergebnisse sind allerdings Int64.

Es leben Kompatibilität und Kontinuität!

Gruß

Dietmar Brüggendiek

[MaBuSE]

Zitat von Brüggendiek:

Wieso sollte das nicht in der Hilfe stehen

Achso - um das zu ermitteln, habe ich nicht das "Orakel von Delphi" gefragt, sondern "Im Namen der DOSe" meinen TURBO gezündet!
Es handelt sich um Optionen, die bei Turbo-Pascal 7.0 (oder auch schon früher) gültig waren und heute keine Bedeutung mehr haben. Deshalb sind sie ja auch nicht mehr dokumentiert.

Es leben Kompatibilität und Kontinuität!

Danke, auf die Idee bin ich gar nicht gekommen

Trotzdem bin ich der Meinung, das selbst wenn diese Schalter keine Bedeutung mehr haben sollten sie dokumentiert sein!

Zitat von Brüggendiek:

Frag's Pferd - oder vielleicht die DP- - warum Delphi die Dinger immer noch mitschleppt.

Was hast Du denn eigentlich immer mit den Pferden?

Ja ja ich weiß:

Zitat:

Das Denken sollte man den Pferden überlassen, die haben einen größeren Kopf.

ps: Danke noch mal für die Antwort.

[edit]dumme Frage oben entfernt[/edit]

[Brüggendiek]

Hallo MaBuSe!

Das Ganze ist doch historisch gewachsen!

Zuerst waren die Computer außen groß (Abmessungen) und innen klein (Leistung), dafür aber sehr teuer.
Man war sogar der Ansicht, daß man den Kernspeicher (kleine Magnetringe auf Drähten, handgestrickt und entsprechend teuer) niemals durch Halbleiter ersetzen können würde. In der damaligen bipolaren Technik hätten 64KByte (Kilobyte! zwischen 2000 und 20000 Watt gebraucht (2000 Watt sind das Kochendwassergerät in der Küche, 20000 Watt der Durchkauferhitzer an der Dusche!). Erst die MOS-Technik schaffte dann Halbleiterspeicher mit realistischem Stromverbrauch.

Weil die Rechner kaum Speicher hatten, mußte man bei den Compilern Beschränkungen in Kauf nehmen. COBOL war hervorragend für Datenausgabe (Ausdrucke) geeignet, die Mathematik war eine Katastrophe. Bei ALGOL und FORTRAN war es umgekehrt.

In dieser Zeit entwickelten Prof. Niklas Wirth und seine Assistentin Kathleen Jensen an der ETH Zürich eine Lernsprache. Diese weurde nach dem französischen Matheatiker Blaise Pascal benannt. PASCAL konnte rechnen und Daten ausgeben. Leider war jedoch der Zugriff auf externe Dateien nur sehr eingeschränkt möglich - und für Lernzwecke auch kaum nötig, da bei den damaligen Lern-Accounts die Rechenaufträge per Lochkarten abgegeben wurden und man keinen Plattenplatz ansprechen durfte.

Dann kamen die Mikroprozessoren und damit auch die Mikrocomputer. Auf Rechnern mit dem 8080-Prozessor (und dem verbesserten Nachfolger Z80) lief das Betriebssystem CP/M.
Programmieren war viel Arbeit: Ändern des Source mit einem Editor, Compiler starten, bei Fehlern von vorne beginnen.
Es compiliert: Linken der Laufzeitbibliothek, Testen (mittels Testausgaben).

Die Firma Borland entwickelte nun die integrierte Umgebung Turbo-Pascal (erforderte allerdings einen Z80). Sie enthielt einen Editor und konnte das erzeugte Programm direkt ausführen. Also nur noch ein Programm für Alles.
Vermutlich wollte man die Sprache "so Pascal wie möglich" gestalten und verzichtete deshalb auf Konstruktionen wie

Code:

ComOpt Bool=On;

Statt dessen schrieb man das Ganze in Kommentare. Dadurch war es möglich, das Programm auf ein anderes System zu portieren - der dortige Compiler ignorierte die TURBO-Steueranweisungen. Schließlich gab es damals noch verschiedene Systeme mit anderen Prozessoren.

Als dann der 8086 (und sein kleiner Bruder 8088 mit 8 Bit Busbreite) erschienen, war das Betriebssystem MS-DOS ein CP/M-Derivat. IBM baute den 8088 in seinen PC ein. Der 80186 (und der 80188) spielten im Rechnerbau keine große Rolle. Im AT kam dann der 80286.
TURBO-PASCAL wurde dann auf MS-DOS portiert.

Der 80286 und seine Nachfolger wurden bei DOS im Real-Mode betrieben (8086 und 8088 kannten nichts anderes). Bei der dort vorhandenen Adressierung gab es bei UP-Aufrufen die Möglichkeit, ein paar Byte über NEAR-CALL zu sparen. Bei einigen Anwendungen mußte das abgeschaltet werden. So entstand die Direktive $F. Im Protected Mode unter Windows (auch 9x) ist das nicht mehr relevant.

Wozu $K gut sein sollte, weiß ich nicht - habe ich nie benutzt.

8086 und 8088 hatten keine Fließkomma-Arithmetik. Dazu gab es den Mathematischen Coprozessor 8087 - ein sehr teures Teil. Um nun den MathCo benutzen zu können, wurde $N eingeführt. Wenn kein MathCo vorhanden ist, konnte man die Hardware durch Software emulieren ($E) - dies geschah über Sprungtabellen und kostete nur für die Initialisierung etwas Rechenzeit. Man aktivierte also üblicherweise N und E gleichzeitig.
Auch bein 80386 gab es noch einen MathCo. Der 80486 enthielt diesen - Prozessoren mit defektem MathCo sollen Gerüchten zufolge mit deaktiviertem MathCo als 80486SX verkauft worden sein. Seit dem Pentium ist der MathCo grundsätzlich im Prozessor. Also sind diese Optionen heute nicht mehr relevant.

Das Real-Mode-Speichermodell erlaubte nur Speicherblöcke bis zu 64KByte! Da kam man schon mal mit dem Stack in Bedrängnis, wenn man tief verschachtelte (z.B. bei Rekursionen). Der Parameter $S compilierte (zeitaufwändige) Routinen zur Stackprüfung ins Programm. Ist ebenfalls heute nicht mehr relevant.


Wenn ein Kommentar eine Compiler-Direktive ist, reagieren TURBO-PASCAL und Delphi auf unbekannte oder fehlerhafte Direktiven mit Fehlermeldungen. Der prozedurale Teil von TP-Programmen kann auch noch unter Delphi verwendet werden. Deshalb sind die veralteten Direktiven immer noch zulässig. Allerdings ist das $E heute neu belegt worden (aber nicht als Schalter).

Vermutlich ist es so, daß die Compiler-internen Daten (die ja auch irgendwo abgespeichert werden) immer erweitert wurden. Deshalb sind auch noch Datenfelder für die heute überflüssigen Direktiven vorhanden - Kompatibilität mit alten Einstellungen und auch Weiterverwendung von Sources des Compilers. Die Frage sollte also nicht heißen, warum das nicht dokumentiert ist. Statt dessen sollte man fragen, warum die CTRL+O-O diese Schalter immer noch in den Source packt. Wer Souces von Delphi nach TP portieren will, sollte die Schalter kennen (und die Voreinstellungen sind wahrscheinlich auch noch wenig praxisgerecht).

Noch eine Frage an Dich: Im Eingangspost fragtest Du nach D7 und hast laut Profil auch D2005. Gibt es da diese Tastenkombination immer noch und packt die auch noch derartig alten Kram rein?

Gruß

Dietmar Brüggendiek

[MaBuSE]

Zitat von Brüggendiek:

Noch eine Frage an Dich: Im Eingangspost fragtest Du nach D7 und hast laut Profil auch D2005. Gibt es da diese Tastenkombination immer noch und packt die auch noch derartig alten Kram rein?

Hallo,

danke für Deinen historischen Abriss, war sehr nett zu lesen.
Ich habe auch die Entwickling mitgemacht.
(Angefangen mit Turbo Pacal 2.0, und dann lange auf 3.0 gearbeitet)
Und ich hatte damals auch bewust {$N-} verwendet. Ich habe mich nur nicht mehr erinnert
Und ich ertappe mich ab und zu wie ich auch noch heute im Delphi Editor Wordstar Befehle verwende. (z.B. Strg+K I oder Strg+K U)

So nun zu Deiner Frage:
Ja ich beschäftige mich schon seit ein paar Monaten mit Delphi 2005.
Momentan bin ich gerade dabei das bei uns eingesetzte Delphi 5 durch Delphi 7 zu ersetzen. (>30 Programmierer)
Später wollen wir auch auf Delphi 2005 updaten.

Mit Strg+O O werden immer noch die Optionen eingefügt.
Sowohl in Win32 als auch in .NET
Bei VCL Anwendungen unterscheiden sich die default Optionen nur in 5 Punkten:

VCL Win32:

{$A8}
{$MINSTACKSIZE $00004000}
{$WARN UNSAFE_TYPE OFF}
{$WARN UNSAFE_CODE OFF}
{$WARN UNSAFE_CAST OFF}

VCL .NET:

{$A-}
{$MINSTACKSIZE $00001000}
{$WARN UNSAFE_TYPE ON}
{$WARN UNSAFE_CODE ON}
{$WARN UNSAFE_CAST ON}

Selbst in WinForms for .NET kann man die Optionen eingügen.
Es sind die selben wie bei VCL for .NET

In C# Builder funktionier das nicht !!!

Hier nochmal die kompletten Rückgaben:

In einer VCL Anwendung für Win32 gibt Strg+O O folgendes zurück:

Delphi-Quellcode:

{$A8,B-,C+,D+,E-,F-,G+,H+,I+,J-,K-,L+,M-,N+,O+,P+,Q-,R-,S-,T-,U-,V+,W-,X+,Y+,Z1}
{$MINSTACKSIZE $00004000}
{$MAXSTACKSIZE $00100000}
{$IMAGEBASE $00400000}
{$APPTYPE GUI}
{$WARN SYMBOL_DEPRECATED ON}
{$WARN SYMBOL_LIBRARY ON}
{$WARN SYMBOL_PLATFORM ON}
{$WARN SYMBOL_EXPERIMENTAL ON}
{$WARN UNIT_LIBRARY ON}
{$WARN UNIT_PLATFORM ON}
{$WARN UNIT_DEPRECATED ON}
{$WARN UNIT_EXPERIMENTAL ON}
{$WARN HRESULT_COMPAT ON}
{$WARN HIDING_MEMBER ON}
{$WARN HIDDEN_VIRTUAL ON}
{$WARN GARBAGE ON}
{$WARN BOUNDS_ERROR ON}
{$WARN ZERO_NIL_COMPAT ON}
{$WARN STRING_CONST_TRUNCED ON}
{$WARN FOR_LOOP_VAR_VARPAR ON}
{$WARN TYPED_CONST_VARPAR ON}
{$WARN ASG_TO_TYPED_CONST ON}
{$WARN CASE_LABEL_RANGE ON}
{$WARN FOR_VARIABLE ON}
{$WARN CONSTRUCTING_ABSTRACT ON}
{$WARN COMPARISON_FALSE ON}
{$WARN COMPARISON_TRUE ON}
{$WARN COMPARING_SIGNED_UNSIGNED ON}
{$WARN COMBINING_SIGNED_UNSIGNED ON}
{$WARN UNSUPPORTED_CONSTRUCT ON}
{$WARN FILE_OPEN ON}
{$WARN FILE_OPEN_UNITSRC ON}
{$WARN BAD_GLOBAL_SYMBOL ON}
{$WARN DUPLICATE_CTOR_DTOR ON}
{$WARN INVALID_DIRECTIVE ON}
{$WARN PACKAGE_NO_LINK ON}
{$WARN PACKAGED_THREADVAR ON}
{$WARN IMPLICIT_IMPORT ON}
{$WARN HPPEMIT_IGNORED ON}
{$WARN NO_RETVAL ON}
{$WARN USE_BEFORE_DEF ON}
{$WARN FOR_LOOP_VAR_UNDEF ON}
{$WARN UNIT_NAME_MISMATCH ON}
{$WARN NO_CFG_FILE_FOUND ON}
{$WARN MESSAGE_DIRECTIVE ON}
{$WARN IMPLICIT_VARIANTS ON}
{$WARN UNICODE_TO_LOCALE ON}
{$WARN LOCALE_TO_UNICODE ON}
{$WARN IMAGEBASE_MULTIPLE ON}
{$WARN SUSPICIOUS_TYPECAST ON}
{$WARN PRIVATE_PROPACCESSOR ON}
{$WARN UNSAFE_TYPE OFF}
{$WARN UNSAFE_CODE OFF}
{$WARN UNSAFE_CAST OFF}
{$WARN OPTION_TRUNCATED ON}
{$WARN WIDECHAR_REDUCED ON}
{$WARN DUPLICATES_IGNORED ON}

In einer VCL- oder WinForms Anwendung für .NET gibt Strg+O O folgendes zurück:

Delphi-Quellcode:

{$A-,B-,C+,D+,E-,F-,G+,H+,I+,J-,K-,L+,M-,N+,O+,P+,Q-,R-,S-,T-,U-,V+,W-,X+,Y+,Z1}
{$MINSTACKSIZE $00001000}
{$MAXSTACKSIZE $00100000}
{$IMAGEBASE $00400000}
{$APPTYPE GUI}
{$WARN SYMBOL_DEPRECATED ON}
{$WARN SYMBOL_LIBRARY ON}
{$WARN SYMBOL_PLATFORM ON}
{$WARN SYMBOL_EXPERIMENTAL ON}
{$WARN UNIT_LIBRARY ON}
{$WARN UNIT_PLATFORM ON}
{$WARN UNIT_DEPRECATED ON}
{$WARN UNIT_EXPERIMENTAL ON}
{$WARN HRESULT_COMPAT ON}
{$WARN HIDING_MEMBER ON}
{$WARN HIDDEN_VIRTUAL ON}
{$WARN GARBAGE ON}
{$WARN BOUNDS_ERROR ON}
{$WARN ZERO_NIL_COMPAT ON}
{$WARN STRING_CONST_TRUNCED ON}
{$WARN FOR_LOOP_VAR_VARPAR ON}
{$WARN TYPED_CONST_VARPAR ON}
{$WARN ASG_TO_TYPED_CONST ON}
{$WARN CASE_LABEL_RANGE ON}
{$WARN FOR_VARIABLE ON}
{$WARN CONSTRUCTING_ABSTRACT ON}
{$WARN COMPARISON_FALSE ON}
{$WARN COMPARISON_TRUE ON}
{$WARN COMPARING_SIGNED_UNSIGNED ON}
{$WARN COMBINING_SIGNED_UNSIGNED ON}
{$WARN UNSUPPORTED_CONSTRUCT ON}
{$WARN FILE_OPEN ON}
{$WARN FILE_OPEN_UNITSRC ON}
{$WARN BAD_GLOBAL_SYMBOL ON}
{$WARN DUPLICATE_CTOR_DTOR ON}
{$WARN INVALID_DIRECTIVE ON}
{$WARN PACKAGE_NO_LINK ON}
{$WARN PACKAGED_THREADVAR ON}
{$WARN IMPLICIT_IMPORT ON}
{$WARN HPPEMIT_IGNORED ON}
{$WARN NO_RETVAL ON}
{$WARN USE_BEFORE_DEF ON}
{$WARN FOR_LOOP_VAR_UNDEF ON}
{$WARN UNIT_NAME_MISMATCH ON}
{$WARN NO_CFG_FILE_FOUND ON}
{$WARN MESSAGE_DIRECTIVE ON}
{$WARN IMPLICIT_VARIANTS ON}
{$WARN UNICODE_TO_LOCALE ON}
{$WARN LOCALE_TO_UNICODE ON}
{$WARN IMAGEBASE_MULTIPLE ON}
{$WARN SUSPICIOUS_TYPECAST ON}
{$WARN PRIVATE_PROPACCESSOR ON}
{$WARN UNSAFE_TYPE ON}
{$WARN UNSAFE_CODE ON}
{$WARN UNSAFE_CAST ON}
{$WARN OPTION_TRUNCATED ON}
{$WARN WIDECHAR_REDUCED ON}
{$WARN DUPLICATES_IGNORED ON}