C - CompilerGNU-gcc Intel/SCO-icc SCO-cc |
Nachfolgend beschreibe ich kurz meine Erfahrungen mit diesen Compilern,
|
Empfohlene Optionen auf der Grundlage meiner Erfahrungen:gcc:gcc -funsigned-char -mcoff -s -O1 \ icc:icc -Xa -w1 -s -O -tp p5 -fp -nofdiv_check *.c -Dbyte="unsigned char" -fp- -O1 -O- -O0 -tp p6 cc (sco):cc -Xa -J -w3 -s -O1 -Kspace *.c (-Kpentium,noinline,frame,nolu) Compiler Kodegröße Geschwindigkeit Bemerkungen gcc 131000 .85 s -s -mcoff -O1 -fu-char Der gcc gewinnt letztlich durch die enorme Fülle von angebotenen
Optionen und wegen Jedenfalls bei meinen Quellkodes sind starke Optimierungen stets schädlich: |
Diese drei Compiler haben jeder für sich eine ganz eigene Art
und Weise,
|
unsigned charIch verwende grundsätzlich und ausnahmslos 'unsigned char'. #if !defined(byte) und verwende im Quelltext kein 'char', um gegebenenfalls flexibel reagieren
zu können. -Dbyte="unsigned char" Es gibt dann einige Warnungen: char <--> unsigned char typedef unsigned char byte; gibt es noch mehr Warnungen wegen <header.h>, weil hierdurch 'byte'
ein unsigned char bietet nur Vorteile, keine Nachteile: Die Programme werden in der Regel kleiner und schneller - auch indirekt. Oftmals muß man char-Typen -letztlich- als Index verwenden,
wie sollte man sonst Übrigens: signed char sc; u= sc; bei den ersten beiden Zuweisungen wird das Vorzeichen bei der Aufweitung
erhalten ! Der Typ (signed) 'char' macht praktisch keinen Sinn. |
Compiler-Vergleich anhand der Assembler-AusgabeEs wurden zwei C-Funktionen zum Testen verwendet, die vom programmierten
Ablauf her Beide Varianten wurden mit den drei Compilern kompiliert. Erzeugte Anzahl von Instruktionszeilen:Compiler Variante 1 Variante 2 gcc 37 37 gcc und icc erzeugen jeweils nahezu vollkommen identischen Kode, C-Test-Funktion (w1.c):int Input(int ityp) C-Test-Funktion (w2.c), logische Funktion genau so wie oben:int Input(int ityp) Die 6 Assembler-Ausgaben:Siehe letzten Tabellenabschnitt. |
gcc 2.8.1 - KompilierungDiese neue Version von März'99 habe ich mit 3 verschiedenen Compilern
versucht zu kompilieren. Der 'cc' hat alloca() eingebaut: -O -Kalloca,... Der 'icc' hat alloca() nicht eingebaut, weshalb alloca.c-->alloca.o
verwendet wurde. Mit gcc 2.7.2.3 klappte die Angelegenheit jedenfalls, |
Erfolgreiche Kompilierung mit 'icc' und selbstentwickelter 'alloca.o'Das ist ein ziemlich starker Hinweis darauf, daß 'alloca.c' aus der gcc-Quelle nicht richtig funktioniert. Die untenstehende 'alloca.s' funktioniert mit dem gcc-Quelltext einwandfrei,
wenn man dafür sorgt, Assembler-Datei alloca.s (ELF): .text Erzeugung von alloca.o: [i]cc -c -belf alloca.s C-Prototyp: void *alloca(unsigned); Stack layout: 1 size-arg Die Funktion ist defensiv angelegt, dadurch, daß 8 Byte (1+2)
auf dem Stack belassen werden, |
Tabelle der Warnmeldungen bei der gcc281-KompilierungNatürlich können die allermeisten Warnungen getrost ignoriert
werden, jedoch würde ich Ich selbst würde beim gegebenen Quelltext-Umfang höchstens 300 Meldungen so stehen lassen... 5 warning: argument `' might be clobbered by `longjmp' or `vfork' |
Die 6 Assembler-Ausgaben:.file "w1.c" ------------------------------------------------------------------- .file "w2.c" -------------------------------------------------------------------------- .ident "SCO Optimizing C Compiler Release 5 Version 2.1.4 P96261" -------------------------------------------------------------------------- .ident "SCO Optimizing C Compiler Release 5 Version 2.1.4 P96261" -------------------------------------------------------------- .file "w1.c" ------------------------------------------------------------------------ .file "w2.c" |