home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turbo Toolbox
/
Turbo_Toolbox.iso
/
turbo4
/
fragen.
< prev
next >
Wrap
Text File
|
1987-12-08
|
18KB
|
399 lines
ALLGEMEINE FRAGEN UND ANTWORTEN
-------------------------------
1. Ist die Größe des Programmcodes und der Daten in irgendeiner
Form begrenzt (wie in der Version 3.0)?
Jedes Modul eines Programms (d.h. jedes Unit und das Hauptprogramm)
arbeitet mit einem (konstanten) Code-Segment und kann deshalb
maximal 64 KByte umfassen. Die Gesamtgröße eines Programms ist nur
durch den verfügbaren Hauptspeicher begrenzt (max. 640 KByte).
Alle globalen Variablen und Konstanten eines Programms werden in einem
Daten-Segment gespeichert und sind nach wie vor auf 64 KByte beschränkt.
Der Heap hat (wie in der Version 3.0) keine Größenbeschränkung. Die
entsprechenden Verwaltungsroutinen arbeiten wesentlich schneller
und effizienter (minimale Blockgröße der Version 3.0: 8 Bytes, in
der Version 4.0: 1 Byte). Zusätzlich läßt sich eine
Fehlerbehandlungsroutine installieren, die automatisch aufgerufen
wird, wenn New oder GetMem der Speicherplatz ausgeht. Kapitel 6 des
Benutzerhandbuchs enthält ein Beispiel zur dynamischen
Speicherverwaltung, Kapitel 25 des Referenzhandbuchs erläutert die
technischen Hintergründe.
2. Ist Turbo Pascal auf MS-DOS-Maschinen lauffähig, die nicht
direkt "kompatibel" sind?
Die Kommandozeilen-Version des Compilers (TPC.EXE) macht überhaupt
keinen Gebrauch von PC-spezifischen Eigenschaften, wenn sie mit dem
Zusatzparameter /Q aufgerufen wird; die Routinen der Units System,
Dos und Printer sollten auf allen DOS-Maschinen lauffähig sein.
Mit Turbo Pascal erzeugte .EXE-Dateien sind deshalb 100%ig DOS-
kompatibel, solange nicht ein oder mehrere der PC-spezifischen
Units (Crt, Graph und Graph3) verwendet werden. Die
Software-Fließkommafunktionen sind auf jeder DOS-Maschine
verwendbar; die 8087-Bibliothek setzt voraus, daß ein
entsprechender Coprozessor installiert ist, der hardwaremäßig in
derselben Weise angesteuert wird wie bei einem Computer der
PC-Serie.
3. Unterstützt die Version 4.0 verschieden große Integerwerte?
Sie tut es - und zwar in jeder denkbaren Form vordefinierter
Integertypen mit 8 Bit (ShortInt, Byte), 16 Bit (Integer, Word) und
32 Bit (LongInt).
4. Wird es neue Versionen der 3.0-Toolboxen geben?
Ja. Alle Toolboxen werden zur Zeit entsprechend überarbeitet und an
die Version 4.0 des Compilers angepaßt. Außerdem werden wir
spezielle Konditionen für den Umtausch alter Versionen anbieten.
5. Läßt sich die Compilierung von Programmteilen von Bedingungen
abhängig machen (wie in Turbo C)?
Ja - wobei nicht nur die Definition von Symbolen (mit {$DEFINE} und
{$UNDEF}) und Prüfungen (mit {$IFDEF..$ELSE..$ENDIF}) möglich sind,
sondern auch Tests von Compiler-Schaltern. Damit lassen sich
beispielsweise Real-Datentypen abhängig davon definieren, ob der
Computer mit einem numerischen Coprozessor ausgerüstet ist oder
nicht. Zusätzlich lassen sich Symbole zur bedingten Compilierung
auch direkt beim Aufruf des Compilers (d.h. ohne Veränderung des
Quelltextes) definieren.
6. Wieviel Platz im Daten-Segment belegt das System, wieviel ist
tatsächlich für das Programm verfügbar?
Der Platzbedarf der Laufzeitbibliothek im Daten-Segment des
Programms hängt davon ab, welche Units aufgenommen werden:
UNIT Datengröße (in Bytes)
---- ---------------------
SYSTEM 585
DOS 6
CRT 26
PRINTER 256
GRAPH 834
TURBO3 256
GRAPH3 0
=========
1963
Die Gesamtgröße des Daten-Segments beträgt 65520 Bytes. Einem
Programm, das nur das Unit System verwendet, stehen also
65520 - 585 = 64935 Bytes
für globale Variablen und Konstanten zur Verfügung.
7. Welche Größe kann eine Datenstruktur maximal haben?
Ein Aufruf von GetMem oder New kann maximal 65521 Bytes auf dem
Heap belegen. Diese Grenze gilt im Prinzip auch für die Deklaration
statischer (globaler) Variablen.
8. Läßt sich feststellen, wieviel Bytes Code und wieviele Bytes
Daten die Compilierung eines Programms oder Units erzeugt?
Innerhalb der integrierten Entwicklungsumgebung compilieren Sie das
entsprechende Modul und wählen dann "Get info" aus dem Menü
Compile.
Die Kommandozeilen-Version von Turbo Pascal gibt die entsprechenden
Daten automatisch am Ende einer Compilierung aus.
9. Inwieweit sind von Turbo Pascal erzeugte Module mit Turbo C und
Turbo Prolog kompatibel?
Mit Turbo C erzeugte .OBJ-Dateien können über den Compiler-Befehl
{$L} in ein Pascal-Programm aufgenommen werden (siehe CPASDEMO.C
und CPASDEMO.PAS auf der Diskette II). Entsprechendes gilt für
.OBJ-Dateien, die mit einem Assembler (MASM oder A86) erzeugt
werden (siehe Kapitel 25). Turbo Pascal erzeugt selbst keine
.OBJ-Dateien, sondern speichert separat compilierte Units in einem
eigenen Format (.TPU). Für dieses eigene Format gibt es eine ganze
Reihe von Gründen:
- .TPU-Dateien enthalten neben dem Object-Code Informationen für
die Fehlersuche und die strenge Typ-Prüfung von Pascal bei der
Einbindung in ein Programm. Trotzdem sind sie wesentlich kleiner
als .OBJ-Dateien.
- .TPU-Dateien erlauben ein "intelligentes" Binden - nicht benutzte
Programmteile werden vom Linker automatisch entfernt.
- Das .TPU-Format ist wesentlich einfacher zu bearbeiten und einer
der Gründe für die hohe Geschwindigkeit des Compilers (bis zu 27000
Zeilen pro Minute).
10. Lassen sich mit {$L} auch Dateien einbinden, die mit anderen
Compilern erzeugt wurden (FORTRAN etc.)?
Das hängt vom Compiler bzw. der Programmiersprache ab. Turbo Pascal
erwartet den gesamten Programmcode einer .OBJ-Datei in *einem*
Segment mit dem Namen CODE, sämtliche Daten müssen ebenfalls in
einem Segment (mit dem Namen DATA) gespeichert sein.
11. Werden unbenutzte Daten-Deklarationen ebenfalls automatisch vom
Linker entfernt?
Nein. Alle Daten, die in einem Programm und seinen Units deklariert
sind, werden auch in die .EXE-Datei eingebunden. Der Linker
entfernt nur unbenutzten Programmcode.
12. Wenn ein Unit in zwei Modulen eines Programm mit uses angeführt
ist, wird es dann auch doppelt in die .EXE-Datei aufgenommen?
Nein. Unabhängig davon, wie komplex die gegenseitigen
Abhängigkeiten einzelner Units und Programmteile aussehen, nimmt
Turbo Pascal von jeder benötigten Prozedur oder Funktion exakt EINE
Kopie in die .EXE-Datei auf - nicht mehr und nicht weniger.
13. Was passiert, wenn Compiler-Schalter in den Modulen eines
Programms unterschiedlich gesetzt sind?
Compiler-Befehle sind "lokal" zum jeweiligen Unit oder dem Haupt-
programm; auch bei einem MAKE oder BUILD beginnt die Compilierung
jedes Moduls mit den über die Menüs bzw. durch die Kommandozeilen-
Parameter gesetzten Standardvorgaben. Die Schalterstellungen
einzelner Module sind also unabhängig voneinander.
14. Ist die Erzeugung eigener Unit-Bibliotheken (.TPL-Dateien)
möglich?
Im Prinzip ja. Die Version 4.0 verwendet allerdings nur eine
einzige Bibliothek (TURBO.TPL). Mit dem Programm TPUMOVER können
Sie TURBO.TPL eigene Units hinzufügen - es wäre also möglich, für
jedes größere Projekt eine separate Version von TURBO.TPL zu
erzeugen.
15. Welche Regeln sind bei der Erstellung von
Interrupt-Behandlungsroutinen zu berücksichtigen?
Abgesehen davon, daß Sie sich mit dem BIOS des Computers und mit
Maschinensprache gut auskennen sollten, gibt es einige Punkte im
Zusammenhang mit Turbo Pascal:
- Verwenden Sie GetIntVec und SetIntVec (aus dem Unit Dos) zur
Veränderung von Interrupt-Vektoren.
- Deklarieren Sie die Behandlungsroutine als interrupt und
verwenden Sie den Compiler-Befehl {$F+} - die Routine muß als FAR
codiert werden.
- Verwenden Sie innerhalb der Behandlungsroutine weder DOS-
Funktionsaufrufe noch Aufrufe der dynamischen Speicherverwaltung
- der entsprechende Code ist nicht reentrant.
16. Wann ist eine Pascal-Routine als NEAR codiert, wann als FAR?
Die allermeisten Programmierer werden sich um dieses Detail nie zu
kümmern brauchen - schließlich wählt der Compiler die richtige Art
des Aufrufs automatisch aus. FAR-Aufrufe und Rücksprünge werden nur
benutzt, wenn
- die Routine im Interface-Teil eines Units deklariert ist
- oder der Compiler-Befehl {$F+} gegeben wurde. Dieser Befehl
sollte für die folgenden Routinen verwendet werden:
+ Interrupt-Behandlung
+ Fehlerbehandlung
+ Exit-Prozeduren
Kapitel 25 enthält weitere Details.
17. Lassen sich mit Turbo Pascal reentrante Routinen schreiben?
Ja, wenn Sie die folgenden Regeln berücksichtigen:
- Alle Daten, die die Routine verändert, müssen sich auf dem Stack
des Prozessors befinden (d.h. lokale Variablen oder übergebene
Parameter sein).
- Typisierte Konstanten werden auch dann im Datensegment
gespeichert, wenn sie lokal deklariert sind. Sie dürfen durch die
Routine nicht verändert werden.
- Punkte, an denen die Routine nicht unterbrochen werden darf,
müssen mit entsprechenden Befehlen (CLI / STI) eingefaßt werden.
- Die Routine darf keine anderen Routinen aufrufen, die ihrerseits
nicht ebenfalls reentrant sind (wie z.B. DOS).
18. Wann sollten die neuen IEEE-Realtypen verwendet werden?
Die neuen Realtypen der Version 4.0 (Single, Double, Extended und
Comp) sind nur dann verfügbar, wenn der Computer mit einem
numerischen Coprozessor ausgerüstet ist (siehe Kapitel 24).
Programme, die für mehrere (unterschiedlich ausgerüstete) Maschinen
gedacht sind, können den Typ Real mit bedingter Compilierung
redeklarieren:
{IFDEF CPU87 } { wenn ein Coprozessor vorhanden ist }
{$N+} { dann 8087-Bibliothek aktivieren }
type
Real = Extended; { und Real als Extended deklarieren }
{$ELSE}
{$N-}
{ Ansonsten wird die Software-Bibliothek verwendet }
{ und die IEEE-Typen werden als Real redeklariert: }
type
Double = Real;
Single = Real;
Comp = Real;
Extended = Real;
{$ENDIF}
19. Was bitte ist der Typ Comp?
Der Datentyp Comp speichert extrem große Integerzahlen - ähnlich
wie bei den BCD-Typen läßt er sich am besten für Operationen
verwenden, bei denen keine Rundungsfehler auftreten dürfen.
Obwohl Comp keine "Stellen nach dem Komma" definiert, lassen sich
Geldbeträge sehr einfach mit Comp-Variablen berechnen, wenn man mit
der Einheit "Pfennig" arbeitet und Ergebnisse bei der Ausgabe durch
100 dividiert.
Hinweis: Der Typ Comp ist nur bei Verwendung eines numerischen
Coprozessors verfügbar.
20. Wieviele signifikante Stellen bieten die IEEE-Realtypen?
Typ signifikante Dezimalstellen Platzbedarf
------------------------------------------------------
Single 7-8 4 Bytes
Double 15-16 8 Bytes
Extended 19-20 10 Bytes
Comp 19-20 8 Bytes
21. Wo und wie werden Zwischenergebnisse bei Operationen mit
IEEE-Realtypen gespeichert?
Zwischenergebnisse haben bei der Verwendung eines numerischen
Coprozessors immer das Format Extended - gespeichert werden sie auf
dem Rechenstack des 8087. Dieser Rechenstack bietet Platz für 8
Werte, was für normale Berechnungen mehr als ausreichend ist. Das
Programm FIB8087.PAS auf der Diskette II demonstriert, wie sich
auch bei rekursiven Funktionsaufrufen Überläufe des Rechenstacks
vermeiden lassen.
22. Wie werden IEEE-Fließkommazahlen gerundet?
Der numerische Coprozessor verwendet ein Rundungsverfahren aus dem
Bankwesen, das sich von der Schulmathematik leicht unterscheidet -
er rundet "Werte in der Mitte" immer zum nächsten *geradzahligen*
Wert hin. Einige Beispiele dazu:
Round(0.4) -> 0 Round(0.5) -> 0 Round(0.6) -> 1
Round(1.4) -> 1 Round(1.5) -> 2 Round(1.6) -> 2
===============
23. Lassen sich Ein-/Ausgaben eines Turbo Pascal-Programms
umleiten?
Solange Sie das Unit Crt *nicht* benutzen, läßt sich ein Turbo
Pascal-Programm beim Aufruf von der DOS-Kommandoebene aus in
derselben Weise umleiten wie ein anderes Programm auch. Wenn Sie
Crt verwenden und sich die Möglichkeit zu Umleitung der
Ein-/Ausgabe offenhalten wollen, können Sie die Textdatei-
Variablen Input und Output mit Assign den Standardwegen von DOS
zuordnen (vgl. Kapitel 25):
Assign(Output,''); Rewrite(Output);
Assign(Input, ''); Rewrite(Input);
24. Wie lassen sich 3.0-Programme konvertieren, die mit
Chain-Dateien arbeiten?
Chain und Execute sind mit .EXE-Dateien nicht möglich. Entweder
compilieren Sie die einzelnen Chain-Dateien als Units oder Sie
verwenden die neue Prozedur Exec (siehe Kapitel 8 und 26).
25. Werden Overlays in der Version 4.0 unterstützt?
Nein - es gibt auch nur noch wenige Gründe für ihre Verwendung: In
der Version 4.0 ist der Gesamtumfang eines Programms nicht auf 64
KByte beschränkt; der Compiler arbeitet außerdem wesentlich
effizienter und dürfte deshalb in vielen Fällen auch dann mit einem
64 KByte-Segment auskommen, in denen die Version 3.0 mit Overlays
arbeiten muß. Falls Sie aus dem einen oder anderen Grund wirklich
nicht ohne Overlays auskommen, sollten Sie entweder die neue
Prozedur Exec zur Verbindung von Programmteilen verwenden oder die
entsprechenden Programme weiterhin mit der Version 3.0 bearbeiten.
(Ein intelligenter Overlay-Manager für zukünftige Versionen von
Turbo Pascal ist in Arbeit).
26. Unterstützt die Version 4.0 das temporäre Sperren gemeinsam
benutzter Dateien und Records für die Verwendung in Netzwerken?
Im Prinzip ja. Das Unit System enthält eine Variable namens
FileMode, über die die Art der Öffnung von Dateien festgelegt
werden kann. Die Laufzeitbibliothek enthält keine speziellen
Funktionen für das Sperren von Records und Dateiteilen (was aber
durch entsprechende Aufrufe von DOS ohne weiteres möglich ist).
27. Wie sieht es mit der größeren Effektivität der Version 4.0 im
direkten Vergleich zur Version 3.0 aus?
Die Programme belegen rund 30% weniger Platz auf der Diskette, die
"typische" Geschwindigkeitssteigerung liegt zwischen 15 und 30%.
28. Unterstützt die Version 4.0 prozedurale Parameter?
Eigentlich nicht - mit dem Operator @ kann einer Routine allerdings
die Adresse einer anderen Routine übergeben werden. Aufrufe von
Funktionen und Prozeduren über Zeiger sind möglich, wenn dazu ein
inline-Makro verwendet wird (siehe PROCPTR.PAS auf der Disk II).
29. Welche Lizenzgebühren müssen für die Weitergabe
selbstentwickelter Turbo Pascal-Programme an Borland gezahlt
werden?
Wie bitte? So etwas haben wir noch nie nötig gehabt.
30. Wie sieht es mit der Fehlersuche auf Maschinenebene aus, d.h.
einem Debugger?
Neben DEBUG kann jeder symbolische Debugger verwendet werden, der
.MAP-Dateien verarbeitet. Das Programm TPMAP (auf der Diskette II)
konvertiert die von Turbo Pascal erzeugten .TPM-Dateien in
.MAP-Dateien und macht so Zeilennummern, Symbolnamen und andere
Informationen für Programme wie SYMDEB, Periscope und PFIX+
verfügbar (siehe Kapitel 9).
31. Gibt es etwas ähnliches wie die statischen lokalen Variablen von C?
Globale Variablen, die im Implementations-Teil eines Units
deklariert sind, werden als lokal zum entsprechenden Unit behandelt
und können über den Initialisierungs-Teil des Units auf
vordefinierte Werte gesetzt werden. Diese Variablen behalten ihre
Werte zwischen mehreren Aufrufen des Units (wie andere globale
Variablen auch).
Typisierte Konstanten, die innerhalb einer Prozedur oder Funktion
deklariert sind, werden im Daten-Segment gespeichert und verhalten
sich exakt wie statische lokale Variablen von C: sie behalten ihren
Wert zwischen mehreren Aufrufen, sind aber lokal zur entsprechenden
Routine.
32. Wo sind die größten Probleme bei der Konvertierung von
3.0-Programmen zu erwarten?
Das hängt natürlich von der Art des Programms ab - mit UPGRADE.EXE
(auf der Diskette II) und den in Kapitel 8 beschriebenen Schritten
sollte eine Konvertierung aber nur in seltenen Fällen größere
Probleme bereiten. UPGRADE kann sogar große Programme in Units
unterteilen (und dabei selbständig die notwendigen Deklarationen
der jeweiligen Interface-Teile erzeugen).
- Die Übergabe von Parametern wird in der Version 4.0 wesentlich
effizienter ausgeführt - dementsprechend dürften bei den meisten
inline-Routinen Änderungen notwendig sein.
- Der Compiler führt eine strengere Typ-Prüfung aus und wird
getrennt deklarierte Typen in einigen Fällen als nicht mit
einander kompatibel ausweisen.
- Die Prozeduren MsDos und Intr erwarten einen Parameter des Typs
Registers, der im Unit Dos deklariert ist und die in der Version
3.0 notwendige Typ-Definition Regs = record .. (AX, BX, CX, DX..)
ersetzt.