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