17.01.2014 Aufrufe

Softwareentwicklung in C - ASC

Softwareentwicklung in C - ASC

Softwareentwicklung in C - ASC

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

2.4 Werkzeuge und Zwischenschritte bei der Programmerstellung 17<br />

Ich möchte hier noch kurz erwähnen, dass es früher durchaus üblich war<br />

(selten auch heute noch), dass der Output e<strong>in</strong>es Compilers selbst Assembler-<br />

Code für die entsprechende Zielplattform war. Danach wurde e<strong>in</strong> Assembler<br />

aufgerufen, der das Übersetzen <strong>in</strong> Object-Code übernahm.<br />

Object-Code<br />

Der Begriff Object-Code bezeichnet Masch<strong>in</strong>encode, der noch nicht direkt<br />

ausführbar ist, da er teilweise noch aus dem Source-Code übernommene symbolische<br />

Namen (z.B. Funktionsaufrufe) enthält. Der Computer versteht aber<br />

<strong>in</strong>tern ke<strong>in</strong>e symbolischen Namen, sondern nur Adressen. Daher stellt der<br />

Object-Code auch nur e<strong>in</strong> Zwischenprodukt dar, das erst <strong>in</strong> e<strong>in</strong>em weiteren<br />

Verarbeitungsschritt (durch den L<strong>in</strong>ker) zu e<strong>in</strong>em Executable wird.<br />

Object-Code entsteht als Resultat der Übersetzung von Source-Code<br />

durch e<strong>in</strong>en Compiler oder Assembler.<br />

Library<br />

Als Library wird e<strong>in</strong>e Zusammenfassung von nützlichen Funktionen, Prozeduren<br />

etc. bezeichnet, die <strong>in</strong> verschiedenen Programmen verwendet werden<br />

können. Im Pr<strong>in</strong>zip liegt e<strong>in</strong>e Library selbst als Object-Code vor. Und<br />

natürlich ist auch hier wieder der L<strong>in</strong>ker verantwortlich, dass e<strong>in</strong>e verwendete<br />

Library zum Executable dazugebunden wird.<br />

Pr<strong>in</strong>zipiell gibt es statische und dynamische Libraries. Statische Libraries<br />

werden zum Zeitpunkt des L<strong>in</strong>kens <strong>in</strong> das ausführbare Programm übernommen,<br />

machen dieses also dementsprechend größer. Dynamische Libraries<br />

werden nicht direkt zum Programm gel<strong>in</strong>kt, sondern es werden nur die entsprechenden<br />

E<strong>in</strong>stiegspunkte im Programm vermerkt. Dynamische Libraries<br />

müssen immer zur Laufzeit e<strong>in</strong>es Programms am entsprechenden Zielrechner<br />

vorhanden se<strong>in</strong>, da es sonst nicht ausführbar ist.<br />

L<strong>in</strong>ker<br />

Der L<strong>in</strong>ker ist dafür verantwortlich, e<strong>in</strong> oder mehrere Files mit Object-Code<br />

und benötigte Libraries zu e<strong>in</strong>em tatsächlich am Computer ausführbaren Programm<br />

zu b<strong>in</strong>den. Hierbei muss er die noch im Object-Code vorhandenen<br />

symbolischen Namen auflösen und durch entsprechende Adressen ersetzen<br />

(=Referenzauflösung). Auch muss der L<strong>in</strong>ker die korrekten E<strong>in</strong>stiegspunkte<br />

bei Verwendung von dynamischen Libraries erzeugen.<br />

Preprocessor<br />

In e<strong>in</strong>igen Sprachen, wie z.B. auch <strong>in</strong> C, wird der Source-Code noch von e<strong>in</strong>em<br />

Preprocessor behandelt, bevor er dem Compiler zur tatsächlichen Überset-

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!