| Zeile 88: | Zeile 88: | ||
=== OS-spezifische Unterstützung === | === OS-spezifische Unterstützung === | ||
| − | [[C]] ist als Kernelsprache nicht perfekt: offensichtlich gibt es keine standardisierte Möglichkeit, den Zugriff auf die Funktionen einer Maschine zu erlauben. Das bedeutet, dass es oft notwendig ist zu Inline-Assembler zurückzugreifen, oder Teile in Assembler zu programmieren und sie mit der Compilerausgabe zur Linkzeit zu linken. Inline-Assembler ermöglicht es euch, Teile von [[C]]-Funktionen in [[Assembler]] zu schreiben und wie gewohnt auf die Variablen von | + | [[C]] ist als Kernelsprache nicht perfekt: offensichtlich gibt es keine standardisierte Möglichkeit, den Zugriff auf die Funktionen einer Maschine zu erlauben. Das bedeutet, dass es oft notwendig ist zu Inline-Assembler zurückzugreifen, oder Teile in Assembler zu programmieren und sie mit der Compilerausgabe zur Linkzeit zu linken. Inline-Assembler ermöglicht es euch, Teile von [[C]]-Funktionen in [[Assembler]] zu schreiben und wie gewohnt auf die Variablen von C-Funktionen zuzugreifen: der Code, den ihr schreibt, wird in den Code, den der Compiler generiert, eingefügt. Die Unterstützung von Inlineassembler variiert unter verschiedenen Compilern, wenn ihr die AT+T-Syntax durchhaltet, ist gcc der Beste unter den PC-Compilern. Obwohl Visual C++ und Borland C++ beide eine vertrautere Intel-Syntax verwenden, sind ihre Inlineassembler nicht genauso stark integriert mit dem Rest der Compiler. Gcc zwingt euch zu einer esoterischen Syntax, aber erlaubt es euch, jegliche C-Ausdrücke als eine Eingabe an einen Assemblerblock zu verwenden und die Ausgaben überall zu platzieren. |
Der resultierende Assembler ist also besser mit dem Optimierer integriert als in den Compilern von Borland und Microsoft: zum Beispiel erlaubt gcc es euch genau anzugeben, welche Register als Resultat eines Assemblerblockes verändert werden. Einiger Assemblercode wird auch im Usermode benötigt, wenn ihr Softwareinterrupts zum Aufrufen von Kernel-Syscall verwendet. Ihr könntet die Interruptaufrufe direkt im Code der C-Bibliothek platzieren (so wie es MS-DOS-Bibliotheken tun),oder eine seperate Bibliothek mit einer Funktion für jeden Aufruf erzeugen und normal darauf verlinken (so wie es Windows NT mit der ntdll.dll macht). Es dürfte auch Sinn machen die betriebssystemabhängige Schnittstelle in eine sprachunabhängige Bibliothek einzufügen, so dass Programme, die in verschiedene Sprachen geschrieben wurden die gleiche Betriebssystembibliothek benutzen können. Das ermöglicht es Leuten, Programme in anderen Sprachen als in C zu schreiben, oder in Sprachen, die keine C-Bindungen erlauben. | Der resultierende Assembler ist also besser mit dem Optimierer integriert als in den Compilern von Borland und Microsoft: zum Beispiel erlaubt gcc es euch genau anzugeben, welche Register als Resultat eines Assemblerblockes verändert werden. Einiger Assemblercode wird auch im Usermode benötigt, wenn ihr Softwareinterrupts zum Aufrufen von Kernel-Syscall verwendet. Ihr könntet die Interruptaufrufe direkt im Code der C-Bibliothek platzieren (so wie es MS-DOS-Bibliotheken tun),oder eine seperate Bibliothek mit einer Funktion für jeden Aufruf erzeugen und normal darauf verlinken (so wie es Windows NT mit der ntdll.dll macht). Es dürfte auch Sinn machen die betriebssystemabhängige Schnittstelle in eine sprachunabhängige Bibliothek einzufügen, so dass Programme, die in verschiedene Sprachen geschrieben wurden die gleiche Betriebssystembibliothek benutzen können. Das ermöglicht es Leuten, Programme in anderen Sprachen als in C zu schreiben, oder in Sprachen, die keine C-Bindungen erlauben. | ||