Sehr schöne Nachricht (zwar schon ein paar Tage alt, aber was solls ). Erwähnenswert ist auch das ebenfalls das OpenBSD den Compiler nun in ihr CVS aufgenommen hat!
Von Christopher Bratusek am Mo, 17. September 2007 um 19:26 #
Soweit ich das verstanden habe ist der PCC ein C Compiler, aber der GCC beinhaltet ja auch C++, OBJ-C, OBJ-C++, Treelang (<- was ist das, ist auf jedenfall optional), Fortran, ADA und JAVA/GCJ.
Der Vergleich trifft es nicht ganz. EGCS war ein Produkt aus verschiedenen experimentellen Forks von GCC und wurde zum Ende seiner Existenz wieder in den GCC eingepflegt. Das Ergebnis war die ueberaus beliebte Version 2.95. Du hast Recht wenn du sagst dass EGCS dem GCC Feuer gemacht hat. Aber PCC spielt in einer anderen Liga als GCC. :) In anderen Worten: wirklich beeindruckt werden die GCC-Jungs davon nicht sein.
Es gibt einen Schritt, der C in von der Sprache unabhängiges Zeugs übersetzt (pass 1), der dann für die Zielmaschine übersetzt wird.
Mir würden die vielen Plattformen fehlen, erst Recht als NetBSD user, bisher gibt es nur i386.
Und man muss wissen, dass "5-10x so schnell" sich auf die Übersetzungszeit bezieht. Ja, und was ist mit dem erzeugten Code? Gibt es überhaupt Optimierungen?
wenn es dich wirklich interessiert dann lies bitte die gcc-interne Dokumentation. Treelang demonstriert wie man eine neue Sprache hinzufügt, also konkrekt, wie man ein neues Frontend schreibt.
Dieses muss für die neue Sprache Syntax- und Semantikprüfungen machen. Danach wird der Code durch das Middleend geführt, dort wird mittels GIMPLE und GENERIC Optimierungen ausgeführt.
Und am Ende wird duch das Backend für die jeweilige Maschine Assemblercode erzeugt.
Eine kurze Übersicht ist: http://de.wikipedia.org/wiki/GNU_Compiler_Collection
Von gcc hasser am Di, 18. September 2007 um 10:10 #
Aber warum sollte man einen für alle haben. Verstöst auch massiv gegen das Grundprinzip von Unix modular und das geeignete Tool für den geeigneten Zweck zu haben.
Und ausserdem für viele (ins. Kernel Entwickler) ist halt 95% ihrer arbeit C (eventuell noch C++). Warum sich dann für 5% diesen Klotz an den Hals binden?
Von Christopher Bratusek am Di, 18. September 2007 um 12:00 #
äußerst intelligenter kommentar; Linus benutzt kein Fortran, für was brauchen dann fortran entwickler einen fortran compiler? Eben! Die können ja auch einfach C lernen! Immer diese Extrawurstler!
Es ist ja nicht so, dass Fortran-Programmierer von diesen einem Compiler abhängen. Ob er also heute schon Fortran unterstützt oder nicht, ist wohl nicht relevant.
Das ist ein nützliches Projekt für alle, die sich mehr Unabhängigkeit von GNU und GPL wünschen.
>> dass der Compiler schlank, schnell und wartbar bleibt
Das hört man immer bei neuen Projekten. Wenn sie dann mal bisschen älter werden regen sich dann darüber wieder alle auf und man baut was mit viel weniger Funktionen und der Kreislauf fängt von Vorne an.
Das stimmt allerdings. Firefox ist mit dem gleichen Anspruch gestartet, und nun gibt es die ersten die Firefox gegen was leichtgewichtiges eintauschen wollen. Das hist alt der ewige Kreislauf. Meines erachtens steht aber am Ende eines solchen Zyklus meist ein ein besseres Stück Software. Von daher finde ich es ok.
Beim Firefox war das aber schon von Anfang an eine Farce, das konnte doch niemand wirklich ernst nehmen. Was will man auch von nem Browser erwarten der auf dem Netscape Code aufbaut...
Von gcc hasser am Di, 18. September 2007 um 10:07 #
Nein leider nicht. Nur grosse Teile. Das leider dazu gezwungen hat eine ganze reihe von Schnittstellen von Netscape zu übernehmen (da auch Mozilla schrittweise Module reimplementiert hat). Und mit vorgegebenen Schnittstellen ist auch die Neuimplementierung sehr sehr eingeschränkt.
Von Anonymous Coward am Mo, 17. September 2007 um 23:06 #
Es war doch von Anfang an klar, dass Firefox nicht wirklich schneller sein würde als die Mozilla-Suite. Die Rendering-Engine wurde ja schließlich komplett übernommen. Der Rest ist doch nur JavaScript- und XUL-Gefrickel...
die jungens und mädels dort wissen schon wie man guten code schreibt, das hat dort schliesslich tradition. würde man die codequalität von netbsd in linux übernehmen, wäre letzteres sogar wirklich gut.
Und Linux würde im Endeffekt wie BSD aussehen, oder was?
Das ganze hast Du aber nicht wirklich zu Ende gedacht oder?
Außerdem teilen sich BSD und Linux viele Dienste, Programme, etc. und damit auch Entwickler. --> daher ist Deine grundlegende Aussage sowieso nicht haltbar
Sie bemängeln vor allem die immer größer werdende Codebasis, die schlechte Wartbarkeit, viele Fehler und die fehlende Geschwindigkeit. »Die Lizenz ist nur das Sahnehäubchen«, schreibt Roy Lai auf undeadly.org.
Also entweder lügen sie sich mit der Relevanz der Lizenzwahl in die Tasche oder sie vollziehen einen vom Aufwand her unverhältnismäßigen Schritt, denn wenn die Lizenz so derart unwichtig gewesen wäre, warum hätte man seine Energie dann nicht in die Verbesserung der GCC gesteckt? Codebasis, Wartbarkeit, Fehler, Geschwindigkeit - alles Dinge, die machbar sind, vor allem, wenn man nicht auf die Idee kommt, einen eigenen Compiler vom Reißbrett zu zaubern, sondern sich stattdessen mit anderen zusammensetzt, um diese Dinge an der GCC zu ändern.
Von einem niemand am Mo, 17. September 2007 um 20:55 #
Die Lizenz mag nicht der Hauptgrund sein warum der Compiler entwickelt wurde, aber sie wird schon der Hauptgrund sein warum er von GPL-Hassern so umjubelt wird, dass sie sich mit einem suboptimalen Compiler rumschlagen.
Was solls, schon der erste Konzern der den Code vereinnahmt, schließt und seine User, die den von ihnen vertriebenen, ehemals freien Code weiter kopieren, mit Klagen und Anwaltskosten überzieht, wird ihnen dankbar sein. Die User, ihr könnts euch denken, nicht.
Und was solls, hinten wedeln die Linux-Leute, die sich mittels Hass auf Windows definieren. So what? Hat nun jeder Troll sein Scherflein zu der Diskussion beigetragen?
> Du hast wirklich nicht die geringste Ahnung wovon du da redest, oder? Woraus schließt Du das?
> Hast du dir schonmal den Code des gcc angeguckt? Tu's besser nicht... Das macht es ökonomischer, über Jahre(!) eine Compilersuite zu entwickeln, die noch nicht einmal vollständiges C mit Inline Assembler beherrscht, geschweige denn Optimierungen oder andere Sprachen?
Andere Sprachen sind nicht wichtig. BSD ist Unix, und Unix ist C. Bis C vollständig unterstützt wird, wird es wohl auch nicht so wahnsinnig lange dauern. Schließlich ist C eine kleine und simple Sprache. Megaoptimierung spielt auch keine so riesen Rolle, vor allem nicht bei OpenBSD.
Und wieder einer der von Software Entwicklung keine Ahnung hast.
Einige Dinge sind per Definition diametral entgegengesetzt. Und dann ist es unmöglich die Grundstrukturen zu ändern, das geht einfach nicht bei einem Projekt dieser Grösse. Daher gibt es nur auslaufen lassen und völlig neu anfangen.
> Und wieder einer der von Software Entwicklung keine Ahnung hast. Ich hab' genug Ahnung davon, keine Sorge.
> Einige Dinge sind per Definition diametral entgegengesetzt. Und dann ist es unmöglich die Grundstrukturen zu ändern, > das geht einfach nicht bei einem Projekt dieser Grösse. An welcher Stelle man für Fehlerkorrekturen oder Geschwindigkeitsprobleme bei einem Projekt wie GCC alles komplett über den Haufen werfen muss und es lohnender ist, etliche Jahre in einen neuen C-Compiler zu stecken, ist mir schleierhaft. Zumal es bereits massig Alternativen gibt, die man stattdessen hätte als Grundlage verwenden können.
> Daher gibt es nur auslaufen lassen und völlig neu anfangen. Und die GCC lassen sie auslaufen? Bitte halte Dich doch an die Themen, um die es geht. Ich weiss, Du bist Deiner Meinung nach der Allergrößte, trotzdem solltest Du zumindest halbwegs beim Thema bleiben.
Sorry aber damit hast du eindeutig deinem ersten Satz "Ich hab' genug Ahnung davon, keine Sorge." Wenn du wirklcih nur einmal diese Codebase von gcc gesehen hättest. Die Konzepte sind auch völlig ungeeignet. Wie viele Compiler hast du schon entworfen? Ich etwa ein halbes Dutzend, das erste mal vor 15 Jahren einen Modula 2 Compiler.
Und sie haben ja eine Alternative genommen, den PCC.
Sie lassen den GCC ja nicht auslaufen. Sie nutzen ihn halt nicht mehr (in Zukunft) für sich. Nochmal hast du bewiesen das du an Pisa Leseschwäche leidest.
> Sorry aber damit hast du eindeutig deinem ersten > Satz "Ich hab' genug Ahnung davon, keine Sorge." Was hab' ich diesem Satz? Entsprochen? Und mir wirfst Du irgendwelche Defizite vor? ;)
> Wenn du wirklcih nur einmal diese Codebase von gcc gesehen hättest. Dann? Was ist dann? Fang doch mal an, statt nur herum zu schwabulieren! Wo sind denn die Defizite in der Codebasis? Weil sie die eine oder andere Zeile mehr benötigen als ein frisch in den Lexer gehackter Mini-C-Compiler? Sie sprachen im Artikel davon, sich dadurch von der GCC lösen zu wollen - dann braucht's schon ein bißchen mehr als das, was Du oder ich in Compilerbau heruntergeschrieben haben.
> Ich etwa ein halbes Dutzend, das erste mal vor 15 > Jahren einen Modula 2 Compiler. Jeder nach seiner Façon, ich habe lieber andere Dinge gemacht. Aber egal, Du bist auf jeden Fall mein Held, keine Sorge. ;)
> Sie lassen den GCC ja nicht auslaufen. Sie nutzen > ihn halt nicht mehr (in Zukunft) für sich. Dann fehlt aber wirklich noch einiges, wenn sie damit ein ganzes System aufbauen wollen, was auch mit über Jahre gewachsenem Code umgehen können soll. Und auch das würde, wenn die Lizenz nur "nebenbei" wichtig wäre, nicht erklären, wieso man sich dafür inzwischen 4 Jahre Zeit genommen hat. Sie hätten Dich anheuern sollen, statistisch brauchst Du ja pro Compiler nur 2.5 Jahre. ;)
> Nochmal hast du bewiesen das du an Pisa Leseschwäche leidest. Blah. Hier, falls Dir die Argumente ausgehen. ;)
Also entweder lügen sie sich mit der Relevanz der Lizenzwahl in die Tasche oder sie vollziehen einen vom Aufwand her unverhältnismäßigen Schritt ...
Vielleicht hast Du einfach das Augenzwickern überlesen? ;-)
Sicher ist die Lizenz ein wichtiger Grund. Unabhängig davon gibt es aber genügend Open Source Projekte, die einen "unverhältnismäßigen" Aufwand betreiben, weil damit Ziele erreicht werden, die nur den Entwicklern wichtig sind.
Warum also sollte man hier strengere Kriterien anlegen?
Wenn's den Jungs Spaß macht und dabei zudem ein funktionsfähiger Compiler herauskommt, dessen Lizenz manche Leute "besser" finden, dann braucht man das nicht zu kritisieren.
> Vielleicht hast Du einfach das Augenzwickern überlesen?;-) Womöglich. Es ist mein Fehler, Leute von Anfang an erstmal ernst zu nehmen, vielleicht sollte ich da etwas zurückrudern. ;)
Das geistert ja nun seit Tagen durch alle möglichen Blogs von *BSD-Fans. Dabei scheint niemand zu berücksichtigen, dass der Compiler nicht optimiert. Kein wunder, dass der dann 5 mal schneller ist, als der GCC. Aber somit ist er auch kein Konkurrent des GCCs.
Der Compiler ist auch noch buggy, da er mit Code ala int main() { int a; foo(); int b; } nicht klar kommt.
Klar kann man Optimierungen hinzufügen. Aber dann ist der Compiler kaum wesentlich schneller als der GCC. Ganz zu schweigen von der unnötigen Arbeit (typisches BSDler NIH).
Die BSDler sollten sich lieber mal LLVM anschauen. Das nutzt zwar die GCC Frontends, aber für C wird afaik gerade ein eigener Frontend entworfen und das Zeugs ist BSD lizensiert (bist auf die GCC Frontends selbst redend).
Außerdem existiert schon seit Jahrzehnten mit TCC ein ähnliches Projekt.
So, nun hört bitte alle auf diese tolle Nachricht, von dem neuen tollen wonderbar Compiler ohne Nachzudenken weiter zu verbreiten. Danke.
> Der Compiler ist auch noch buggy, da er mit Code > ala int main() { int a; foo(); int b; } nicht klar kommt.
In C90 ist das ja auch nicht offiziell unterstützt, nur weil der GCC das grundsätzlich wie C++ verarbeitet bedeutet das ja nicht, dass es richtig ist.
$ cat test.c int main() { int a; a++; int b; } $ gcc -ansi -pedantic test.c test.c: In function 'main': test.c:1: warning: ISO C90 forbids mixed declarations and code
Und die Tatsache, dass du beim gcc erst in einen C99-Modus schalten musst sagt uns was? Sehr verbreitet scheint C99 noch nicht zu sein und auch beim GCC ist der alte Standard noch Standard.
stimmt C99 ist nicht default. Das heisst aber nicht, dass C99 nicht doch verbreitet ist. Es heisst auch nicht, dass alle Defaulteinstellungen des gcc sinnvoll sind, und man aus diesen Rueckschluesse ziehen kann.
Von Anonymous Coward am Mo, 17. September 2007 um 23:22 #
Es stimmt einfach nicht, dass der Compiler nicht optimiert. "The only optimization added so far is a multiple-register-class graph-coloring register allocator, which may be one of the best register allocators today." Siehe da: http://preview.tinyurl.com/2ras8j
Mich würde eher interessieren wie es mit der Performance des übersetzten Codes aussieht. Dort mal ein paar Benchmarks und es sieht bestimmt nicht so rosig aus wie die Compile-Zeit.
Sauberer, portabler, dokumentierter und freier Code. Dafür lohnt sich jeder Aufwand. Während andere von ihrem OS aus dem Märchenwald fabulieren, existiert dort ein richtiges UNIX-OS.
Von Anonymous Coward am Di, 18. September 2007 um 04:56 #
Zunächst mal ist die (sic!) GCC frei. Der Begriff der "freien" Software stammt von RMS, und dieser definierte sie über vier Kriterien, die jede Software unter GPL erfüllt. Wie sauber und dokumentiert der GCC-Code ist, vermag ich nicht zu beurteilen. Portabel ist er jedenfalls, denn die GCC läuft ja auf sehr vielen Plattformen. Außerdem ist der vom pcc erzeugte Code ja anscheinend ziemlich mies, so dass IMO kaum etwas für diesen Compiler spricht. Zumal es mit llvm schon eine sehr viel weiter fortgeschrittene Compiler-Technologie gibt, für die nur noch ein BSD-lizenziertes C-Frontend fehlt.
Von anonymous am Di, 18. September 2007 um 10:48 #
Schön, dass du den Begriff frei in Freier Software in Anführungszeichen gesetzt hast. ;)
Die GCC unterstützt viele Plattformen, das ist richtig. Aber leider verschwindet die eine oder andere dann von einem Release zum nächsten, das kann unter Umständen sehr ärgerlich sein, wenn du nämlich auf diese Architektur portieren wolltest (oder portiert hast).
Du möchtest ein Beispiel?
Also, those for some individual systems have been obsoleted: SPARC family SPARClite-based systems (sparclite-*-coff, sparclite-*-elf, sparc86x-*-elf) OpenBSD 32-bit (sparc-*-openbsd*)
Quelle: http://gcc.gnu.org/gcc-4.0/changes.html
Und schon bist du dazu gezwungen, bei einer älteren Version zu bleiben. Stört momentan nicht, da GCC in Version 2.95.3 und 3.3.5 verwendet wird. Ist aber auch ein ärgerlicher Punkt: Wegen solchen Änderungen wäre man gezwungen, mehrere GCCs zu pflegen, was nicht einmal die GCC-Entwickler selbst mehrere Versionen hinweg machen (wozu auch?).
Und bezüglich PCC: Es kommt auf die Compilegeschwindigkeit an, nicht auf das Endprodukt. In den meisten Fällen kann eine Optimierung des Compilers wirklich kein Argument sein, zum Beispiel bei den ganzen Programmen in bin/ oder usr.bin/. Mal im Ernst, wer will denn ls optimieren (wenn nicht auf Größe)? Wenn das System schnell durchkompiliert, dann können auch öfter Snapshots bereitgestellt werden, welche dann auch wieder öfter getestet werden können. Das ist der Vorteil.
Aber bis dahin dauert es sowieso noch eine halbe Ewigkeit, zum Beispiel müsste man erst einmal Propolice auf PCC portieren. Darauf will nun wirklich keiner verzichten.
So unrecht hat er nicht. Vor allem bei kleinen Systemtools sind die Optimierungen absolut irrelevant. Auch bei Tools wie bzip2, gzip oder OpenSSL kann man die Compileroptimierungen in die Tonne hauen. Sie bewegen sich alle um einstelligen Prozentbereich, wenn überhaupt. Einzig für bestimmte Applikationen sind Optimierungen sinnvoll und für die paar Tools kann man immer noch den GCC oder den ICC einsetzen.
Wie gut dass jedes ordentliche Linux oder Unix jede Menge Skripte hat, die lauter kleine Systemtools aufrufen, die man ja eh nicht optimieren muss... Ein ordentlicher Unixserver bootet schließlich nur einmal im Leben. :p
Und weil Binärdistributionen des Teufels sind (schließlich könnte dann ja jede Oma mich mit Unixsupportfragen nerven) muss ein Unix zwingend aus den Quellen gebaut werden. Ach und weil perfekt optimierte Compiler so unwichtig sind, ist Fortran ja auch im Numerikbereich ausgestorben...
Ironie beiseite: Bevor man solche Aussagen macht sollte man mit Tools wie Valgrind (KChachgrind) auf die Performancesuche machen, da dürfte man so manches kleine Wunder erleben, welche ach so harmlose fitzelige Systemroutine plötzlich der große Bremsklotz ist.
Dann würde man: 1) Den Quelltext des Programms sinnvoll optimieren. 2) an sinnvollen Stellen sinnvolle Compileflags einsetzen. Die ganze Flagorgie haben wir schließlich den "alles aus den Quellen selbst Machern" zu verdanken, was dann schließlich in Gentoo kulmulierte.
Von anonymous am Di, 18. September 2007 um 11:55 #
Ja, und das nächste Mal im Zusammenhang zitieren, ok?
Wie gesagt: Die Programme im Basisssytem benötigen nun wirklich keine Optimierung, und wenn, dann geschehen diese durch Überarbeitung des Codes, nicht durch irgendwelche Compileroptimierungen. Und ich wiederhole mich: Es geht darum, schneller Snapshots bereitstellen zu können, damit öfter getestet wird. Dafür braucht man Compilergeschwindigkeit, nicht Endprogrammgeschwindigkeit.
Außerdem wird die GCC sicherlich niemals vollständig entfernt, eben auch "weil es dann doch auf die Geschwindigkeit des Endprodukts ankommt", oder weil einfach zu viele Programme in den Ports die GCC benötigen.
Es gibt auch GNU make in den Ports, weil -C eine Erweiterung ist, die von zu vielen autotools-Paketen benötigt wird (die es auch in den Ports gibt - man staune). Da hat auch keiner ein Problem mit. BSD make kann (und will) es nicht, ist aber trotzdem im Basissystem. Wenn "cc" nicht ausreicht, wird halt "gcc" nachinstalliert ... ;)
Und GCC gibt es auch in neueren Versionen in den Ports, zumindest für die Plattformen, die noch unterstützt werden.
Ah, OK. Also ist der PCC für kleine "unwichtige" Programme, bei denen man auf die Optimierung verzichten kann. Für alles andere verwendet man einen vernünftigen Compiler.... *nachdenk* lohnt sich die Arbeit überhaupt für einen solchen Nischen-Compiler? *nachdenk*
Von anonymous am Di, 18. September 2007 um 12:25 #
* Unterstützung für Plattformen sind direkt in der Hand der Entwickler und nicht abhängig von der Entscheidung der GCC-Entwickler, ob es sich noch lohnt oder nicht (siehe sparc). * (Unterpunkt:) eine Compilerversion für alle Plattformen * Snapshots sind deutlich schneller verfügbar, auch für Architekturen mit wenig CPU-Power. * ca. 150 MB (gcc) gegen 2 MB (pcc) -> Codeaudit besser möglich - oder vielleicht traut sich jetzt erst der eine oder andere mal zu gucken, wie so ein Compiler funktioniert.
* Das "Sahnehäubchen" GPL -> BSDL ... Na ja. Ich seh da keinen großen Gewinn, denn die binutils sind nach wie vor ein wichiger Bestandteil.
> * Unterstützung für Plattformen sind direkt in der Hand der Entwickler und nicht abhängig von der Entscheidung der GCC-Entwickler Dafür würde auch ein Fork des GCC reichen.
> * (Unterpunkt:) eine Compilerversion für alle Plattformen Ebenfalls. Man hätte sich bei der GCC auch für die rausgeworfenen Plattformen einsetzen können.
> * Snapshots sind deutlich schneller verfügbar, auch für Architekturen mit wenig CPU-Power. Hmja. Dafür gibt's aber auch Compiler. Was spricht gegen den Fork der GCC 2.95 oder eines gänzlich anderen, bereits existierenden?
> * ca. 150 MB (gcc) gegen 2 MB (pcc) -> Codeaudit besser möglich Eine komplette Neuentwicklung braucht wirklich ein Audit...
Von indischer freund am Di, 18. September 2007 um 15:01 #
Ich benutze valac mit tcc und bin sehr zufrieden. Kann nicht verstehen, warum so viele Leute gegeüber einen schlanken c-compiler so skeptisch sind. Der tcc ist blitzschnell. Das executable ist zugegeben nicht so schnell wie das mit gcc-compilierte, aber noch um Welten besser als Python und Co. Ein guter Kompromiss eben.
Von anonymous am Di, 18. September 2007 um 15:16 #
Ach komm, Audits sind nun wirklich so tief in die Philosophie von OpenBSD verankert, dass man nicht anzweifeln sollte, dass das ein fundamental wichtiger Aspekt ist. Die GCC entzieht sich allerdings genau wie GNU cvs (Ersatz dafür soll OpenCVS werden) diesen Audits, weil der Quelltext ... nun, es gibt nicht viele Entwickler, die ihre Zeit opfern wollen, Quelltexte zu untersuchen, die sich an fast keine Stilvorlage halten.
Den Aufwand für ein PCC-Audit dann nochmal mindestens mal 75, da kommst du schon an die Grenzen der Manpower. :)
Dazu kommt, dass bei einer neuen Version dann mit großer Sicherheit wieder alles über den Haufen geworfen wird und man beginnt von neuem. Und wenn man einen Fork hat, dann wird es auch nicht einfacher, die Bugfixes aus den neuen Versionen in die alten einzubauen.
> Dafür gibt's aber auch Compiler.
Ich glaube, dass du wohl Crosscompiler meinst. Die werden mit Absicht nicht genommen, da eine native Übersetzung das System unter Last setzt und man schneller Systemfehler entdecken kann.
Zunächst einmal, die Begriffe frei, Freiheit, Software sind Allgemeingut und existierten schon lange vor RMS, vor allem in ihrer korrekten Bedeutung. Desweiteren definiert RMS folgends, um sich dieser allgemeinen Bedeutung zu bedienen: free as in freedom. Ich denke die Übersetzung bekommst du noch allein hin. Wenn ich garantierte Freiheit möchte, lausche ich Bush, Schäuble und auch RMS. Wenn ich echte Freiheit möchte, entferne ich mich von diesen Leuten soweit es nur geht. Ein Copyleft ist eben kein Parameter von Freiheit, Castro in Kuba lässt auch die Leute nicht mitreden, um den Erfolg der Revolution zu garantieren.
Wie gut, dass du ohne RMS sicher heute an deiner freien Unixmaschine sitzen würdest... BSD kann alles besser und braucht diese ganze kindische Linux/GPL/FSF-Soße nicht, jajaja (aber dann nach 10 Jahren sich nen Mac kaufen, weil "das is ja Unix").
Mann ich sag ja auch nicht dass mein Pinguin schöner ist und mehr kann als dein Teufelchen, auch wenn es manchmal stimmt.
Von Anonymous am Di, 18. September 2007 um 02:04 #
demon: Die Meldung enthaelt leider ein paar Punkte, die so nicht stimmen. PCC wurde _nicht_ in NetBSD aufgenommen (lediglich in pkgsrc) und ist _nicht_ im offiziellen CVS Repository von NetBSD. Ausserdem gibt es bislang keinen konkreten Plan GCC durch PCC zu ersetzen.
ja und er hat vollkommen Recht, der einer der drei Links führt zur __OpenBSD__ CVS Repository Mailinglist! ANsonsten steht da nur das jetzt jemand mit PCC experimientiert hat und es im pkgsrc ist.
ccache is a compiler cache. It acts as a caching pre-processor to C/C++ compilers, using the -E compiler switch and a hash to detect when a compilation can be satisfied from cache. This often results in a 5 to 10 times speedup in common compilations.
Von Dr. Halbbit am Di, 18. September 2007 um 23:05 #
...also wenn der dann alle NetBSD-Plattformen unterstützt, sind wie dem Ziel eines GPL-freien SuperBSDs wieder ein Stück näher... so in 10 Jahren oder so... immerhinque!
Tendra schien mir eigentlich immer ziemlich weit fortgeschritten zu sein. Zumindest konnte ich damit meine eigenen Programme unter Linux übersetzen und auch zum Laufen bringen. Nur 64-bit-Arithmetik auf 32-bit-Maschinen schien ziemlich buggy zu sein.
Erwähnenswert ist auch das ebenfalls das OpenBSD den Compiler nun in ihr CVS aufgenommen hat!
Was wird mit diesen Sprachen?
Egal, find ich gut, Konkurrenz belebt das Geschäft.
Erinnert sich noch wer an EGCS?
Die haben die GCC-Jungs damals ganz schön aufgemischt. Seit dem gibt es regelmäßige Releases. Vielleicht passiert mal wieder mehr
In anderen Worten: wirklich beeindruckt werden die GCC-Jungs davon nicht sein.
Aber vor allem in punkto Geschwindigkeit kann man GCC ordentlich anheizen.
Mal schaun was geschieht.
Mir würden die vielen Plattformen fehlen, erst Recht als NetBSD user, bisher gibt es nur i386.
Und man muss wissen, dass "5-10x so schnell" sich auf die Übersetzungszeit bezieht. Ja, und was ist mit dem erzeugten Code? Gibt es überhaupt Optimierungen?
Gruss,
Kay
Keep it real !
wenn es dich wirklich interessiert dann lies bitte die gcc-interne Dokumentation.
Treelang demonstriert wie man eine neue Sprache hinzufügt, also konkrekt, wie man ein neues Frontend schreibt.
Dieses muss für die neue Sprache Syntax- und Semantikprüfungen machen. Danach wird der Code durch das Middleend geführt, dort wird mittels GIMPLE und GENERIC Optimierungen ausgeführt.
Und am Ende wird duch das Backend für die jeweilige Maschine Assemblercode erzeugt.
Eine kurze Übersicht ist: http://de.wikipedia.org/wiki/GNU_Compiler_Collection
Und ausserdem für viele (ins. Kernel Entwickler) ist halt 95% ihrer arbeit C (eventuell noch C++). Warum sich dann für 5% diesen Klotz an den Hals binden?
Das ist ein nützliches Projekt für alle, die sich mehr Unabhängigkeit von GNU und GPL wünschen.
Das hört man immer bei neuen Projekten. Wenn sie dann mal bisschen älter werden regen sich dann darüber wieder alle auf und man baut was mit viel weniger Funktionen und der Kreislauf fängt von Vorne an.
mfg
wdsl
Das ganze hast Du aber nicht wirklich zu Ende gedacht oder?
Außerdem teilen sich BSD und Linux viele Dienste, Programme, etc. und damit auch Entwickler. --> daher ist Deine grundlegende Aussage sowieso nicht haltbar
Also entweder lügen sie sich mit der Relevanz der Lizenzwahl in die Tasche oder sie vollziehen einen vom Aufwand her unverhältnismäßigen Schritt, denn wenn die Lizenz so derart unwichtig gewesen wäre, warum hätte man seine Energie dann nicht in die Verbesserung der GCC gesteckt? Codebasis, Wartbarkeit, Fehler, Geschwindigkeit - alles Dinge, die machbar sind, vor allem, wenn man nicht auf die Idee kommt, einen eigenen Compiler vom Reißbrett zu zaubern, sondern sich stattdessen mit anderen zusammensetzt, um diese Dinge an der GCC zu ändern.
lg
Erik
Was solls, schon der erste Konzern der den Code vereinnahmt, schließt und seine User, die den von ihnen vertriebenen, ehemals freien Code weiter kopieren, mit Klagen und Anwaltskosten überzieht, wird ihnen dankbar sein. Die User, ihr könnts euch denken, nicht.
Wie pubertär ...
Woraus schließt Du das?
> Hast du dir schonmal den Code des gcc angeguckt? Tu's besser nicht...
Das macht es ökonomischer, über Jahre(!) eine Compilersuite zu entwickeln, die noch nicht einmal vollständiges C mit Inline Assembler beherrscht, geschweige denn Optimierungen oder andere Sprachen?
lg
Erik
Bis C vollständig unterstützt wird, wird es wohl auch nicht so wahnsinnig lange dauern. Schließlich ist C eine kleine und simple Sprache.
Megaoptimierung spielt auch keine so riesen Rolle, vor allem nicht bei OpenBSD.
Einige Dinge sind per Definition diametral entgegengesetzt. Und dann ist es unmöglich die Grundstrukturen zu ändern, das geht einfach nicht bei einem Projekt dieser Grösse. Daher gibt es nur auslaufen lassen und völlig neu anfangen.
Ich hab' genug Ahnung davon, keine Sorge.
> Einige Dinge sind per Definition diametral entgegengesetzt. Und dann ist es unmöglich die Grundstrukturen zu ändern,
> das geht einfach nicht bei einem Projekt dieser Grösse.
An welcher Stelle man für Fehlerkorrekturen oder Geschwindigkeitsprobleme bei einem Projekt wie GCC alles komplett über den Haufen werfen muss und es lohnender ist, etliche Jahre in einen neuen C-Compiler zu stecken, ist mir schleierhaft. Zumal es bereits massig Alternativen gibt, die man stattdessen hätte als Grundlage verwenden können.
> Daher gibt es nur auslaufen lassen und völlig neu anfangen.
Und die GCC lassen sie auslaufen? Bitte halte Dich doch an die Themen, um die es geht. Ich weiss, Du bist Deiner Meinung nach der Allergrößte, trotzdem solltest Du zumindest halbwegs beim Thema bleiben.
lg
Erik
Wenn du wirklcih nur einmal diese Codebase von gcc gesehen hättest. Die Konzepte sind auch völlig ungeeignet. Wie viele Compiler hast du schon entworfen? Ich etwa ein halbes Dutzend, das erste mal vor 15 Jahren einen Modula 2 Compiler.
Und sie haben ja eine Alternative genommen, den PCC.
Sie lassen den GCC ja nicht auslaufen. Sie nutzen ihn halt nicht mehr (in Zukunft) für sich.
Nochmal hast du bewiesen das du an Pisa Leseschwäche leidest.
> Satz "Ich hab' genug Ahnung davon, keine Sorge."
Was hab' ich diesem Satz? Entsprochen? Und mir wirfst Du irgendwelche Defizite vor? ;)
> Wenn du wirklcih nur einmal diese Codebase von gcc gesehen hättest.
Dann? Was ist dann? Fang doch mal an, statt nur herum zu schwabulieren! Wo sind denn die Defizite in der Codebasis? Weil sie die eine oder andere Zeile mehr benötigen als ein frisch in den Lexer gehackter Mini-C-Compiler? Sie sprachen im Artikel davon, sich dadurch von der GCC lösen zu wollen - dann braucht's schon ein bißchen mehr als das, was Du oder ich in Compilerbau heruntergeschrieben haben.
> Ich etwa ein halbes Dutzend, das erste mal vor 15
> Jahren einen Modula 2 Compiler.
Jeder nach seiner Façon, ich habe lieber andere Dinge gemacht. Aber egal, Du bist auf jeden Fall mein Held, keine Sorge. ;)
> Sie lassen den GCC ja nicht auslaufen. Sie nutzen
> ihn halt nicht mehr (in Zukunft) für sich.
Dann fehlt aber wirklich noch einiges, wenn sie damit ein ganzes System aufbauen wollen, was auch mit über Jahre gewachsenem Code umgehen können soll. Und auch das würde, wenn die Lizenz nur "nebenbei" wichtig wäre, nicht erklären, wieso man sich dafür inzwischen 4 Jahre Zeit genommen hat. Sie hätten Dich anheuern sollen, statistisch brauchst Du ja pro Compiler nur 2.5 Jahre. ;)
> Nochmal hast du bewiesen das du an Pisa Leseschwäche leidest.
Blah. Hier, falls Dir die Argumente ausgehen. ;)
lg
Erik
Vielleicht hast Du einfach das Augenzwickern überlesen? ;-)
Sicher ist die Lizenz ein wichtiger Grund. Unabhängig davon gibt es aber genügend Open Source Projekte, die einen "unverhältnismäßigen" Aufwand betreiben, weil damit Ziele erreicht werden, die nur den Entwicklern wichtig sind.
Warum also sollte man hier strengere Kriterien anlegen?
Wenn's den Jungs Spaß macht und dabei zudem ein funktionsfähiger Compiler herauskommt, dessen Lizenz manche Leute "besser" finden, dann braucht man das nicht zu kritisieren.
Womöglich. Es ist mein Fehler, Leute von Anfang an erstmal ernst zu nehmen, vielleicht sollte ich da etwas zurückrudern. ;)
lg
Erik
Der Compiler ist auch noch buggy, da er mit Code ala int main() { int a; foo(); int b; } nicht klar kommt.
Klar kann man Optimierungen hinzufügen. Aber dann ist der Compiler kaum wesentlich schneller als der GCC. Ganz zu schweigen von der unnötigen Arbeit (typisches BSDler NIH).
Die BSDler sollten sich lieber mal LLVM anschauen. Das nutzt zwar die GCC Frontends, aber für C wird afaik gerade ein eigener Frontend entworfen und das Zeugs ist BSD lizensiert (bist auf die GCC Frontends selbst redend).
Außerdem existiert schon seit Jahrzehnten mit TCC ein ähnliches Projekt.
So, nun hört bitte alle auf diese tolle Nachricht, von dem neuen tollen wonderbar Compiler ohne Nachzudenken weiter zu verbreiten. Danke.
> ala int main() { int a; foo(); int b; } nicht klar kommt.
In C90 ist das ja auch nicht offiziell unterstützt, nur weil der GCC das grundsätzlich wie C++ verarbeitet bedeutet das ja nicht, dass es richtig ist.
$ cat test.c
int main() { int a; a++; int b; }
$ gcc -ansi -pedantic test.c
test.c: In function 'main':
test.c:1: warning: ISO C90 forbids mixed declarations and code
Abgesehen davon gebe ich dir aber Recht.
Mit dem aktuellen Standard (c99) ist das perfekt vereinbar:
$gcc -std=c99 -pedantic test.c
wird übersetzt.
Warum sollte ein neuer Kompiler einen alten Standard implementieren?
Sehr verbreitet scheint C99 noch nicht zu sein und auch beim GCC ist der alte Standard noch Standard.
Es heisst auch nicht, dass alle Defaulteinstellungen des gcc sinnvoll sind,
und man aus diesen Rueckschluesse ziehen kann.
Gruss
Urs
"The only optimization added so far is a multiple-register-class graph-coloring register allocator, which may be one of the best register allocators today."
Siehe da:
http://preview.tinyurl.com/2ras8j
Dort mal ein paar Benchmarks und es sieht bestimmt nicht so rosig aus wie die Compile-Zeit.
Und wenn doch - weiter so.
Wie sauber und dokumentiert der GCC-Code ist, vermag ich nicht zu beurteilen. Portabel ist er jedenfalls, denn die GCC läuft ja auf sehr vielen Plattformen. Außerdem ist der vom pcc erzeugte Code ja anscheinend ziemlich mies, so dass IMO kaum etwas für diesen Compiler spricht. Zumal es mit llvm schon eine sehr viel weiter fortgeschrittene Compiler-Technologie gibt, für die nur noch ein BSD-lizenziertes C-Frontend fehlt.
Die GCC unterstützt viele Plattformen, das ist richtig. Aber leider verschwindet die eine oder andere dann von einem Release zum nächsten, das kann unter Umständen sehr ärgerlich sein, wenn du nämlich auf diese Architektur portieren wolltest (oder portiert hast).
Du möchtest ein Beispiel?
Also, those for some individual systems have been obsoleted:
SPARC family
SPARClite-based systems (sparclite-*-coff, sparclite-*-elf, sparc86x-*-elf)
OpenBSD 32-bit (sparc-*-openbsd*)
Quelle: http://gcc.gnu.org/gcc-4.0/changes.html
Und schon bist du dazu gezwungen, bei einer älteren Version zu bleiben. Stört momentan nicht, da GCC in Version 2.95.3 und 3.3.5 verwendet wird. Ist aber auch ein ärgerlicher Punkt: Wegen solchen Änderungen wäre man gezwungen, mehrere GCCs zu pflegen, was nicht einmal die GCC-Entwickler selbst mehrere Versionen hinweg machen (wozu auch?).
Und bezüglich PCC: Es kommt auf die Compilegeschwindigkeit an, nicht auf das Endprodukt. In den meisten Fällen kann eine Optimierung des Compilers wirklich kein Argument sein, zum Beispiel bei den ganzen Programmen in bin/ oder usr.bin/. Mal im Ernst, wer will denn ls optimieren (wenn nicht auf Größe)? Wenn das System schnell durchkompiliert, dann können auch öfter Snapshots bereitgestellt werden, welche dann auch wieder öfter getestet werden können. Das ist der Vorteil.
Aber bis dahin dauert es sowieso noch eine halbe Ewigkeit, zum Beispiel müsste man erst einmal Propolice auf PCC portieren. Darauf will nun wirklich keiner verzichten.
*lol* der war gut!
Und weil Binärdistributionen des Teufels sind (schließlich könnte dann ja jede Oma mich mit Unixsupportfragen nerven) muss ein Unix zwingend aus den Quellen gebaut werden. Ach und weil perfekt optimierte Compiler so unwichtig sind, ist Fortran ja auch im Numerikbereich ausgestorben...
Ironie beiseite: Bevor man solche Aussagen macht sollte man mit Tools wie Valgrind (KChachgrind) auf die Performancesuche machen, da dürfte man so manches kleine Wunder erleben, welche ach so harmlose fitzelige Systemroutine plötzlich der große Bremsklotz ist.
Dann würde man:
1) Den Quelltext des Programms sinnvoll optimieren.
2) an sinnvollen Stellen sinnvolle Compileflags einsetzen. Die ganze Flagorgie haben wir schließlich den "alles aus den Quellen selbst Machern" zu verdanken, was dann schließlich in Gentoo kulmulierte.
Wie gesagt: Die Programme im Basisssytem benötigen nun wirklich keine Optimierung, und wenn, dann geschehen diese durch Überarbeitung des Codes, nicht durch irgendwelche Compileroptimierungen. Und ich wiederhole mich: Es geht darum, schneller Snapshots bereitstellen zu können, damit öfter getestet wird. Dafür braucht man Compilergeschwindigkeit, nicht Endprogrammgeschwindigkeit.
Außerdem wird die GCC sicherlich niemals vollständig entfernt, eben auch "weil es dann doch auf die Geschwindigkeit des Endprodukts ankommt", oder weil einfach zu viele Programme in den Ports die GCC benötigen.
Es gibt auch GNU make in den Ports, weil -C eine Erweiterung ist, die von zu vielen autotools-Paketen benötigt wird (die es auch in den Ports gibt - man staune). Da hat auch keiner ein Problem mit. BSD make kann (und will) es nicht, ist aber trotzdem im Basissystem. Wenn "cc" nicht ausreicht, wird halt "gcc" nachinstalliert ... ;)
Und GCC gibt es auch in neueren Versionen in den Ports, zumindest für die Plattformen, die noch unterstützt werden.
Und jetzt mal wieder munter zerpflücken!
* (Unterpunkt:) eine Compilerversion für alle Plattformen
* Snapshots sind deutlich schneller verfügbar, auch für Architekturen mit wenig CPU-Power.
* ca. 150 MB (gcc) gegen 2 MB (pcc) -> Codeaudit besser möglich - oder vielleicht traut sich jetzt erst der eine oder andere mal zu gucken, wie so ein Compiler funktioniert.
* Das "Sahnehäubchen" GPL -> BSDL ... Na ja. Ich seh da keinen großen Gewinn, denn die binutils sind nach wie vor ein wichiger Bestandteil.
Dafür würde auch ein Fork des GCC reichen.
> * (Unterpunkt:) eine Compilerversion für alle Plattformen
Ebenfalls. Man hätte sich bei der GCC auch für die rausgeworfenen Plattformen einsetzen können.
> * Snapshots sind deutlich schneller verfügbar, auch für Architekturen mit wenig CPU-Power.
Hmja. Dafür gibt's aber auch Compiler. Was spricht gegen den Fork der GCC 2.95 oder eines gänzlich anderen, bereits existierenden?
> * ca. 150 MB (gcc) gegen 2 MB (pcc) -> Codeaudit besser möglich
Eine komplette Neuentwicklung braucht wirklich ein Audit...
lg
Erik
Bye
Den Aufwand für ein PCC-Audit dann nochmal mindestens mal 75, da kommst du schon an die Grenzen der Manpower. :)
Dazu kommt, dass bei einer neuen Version dann mit großer Sicherheit wieder alles über den Haufen geworfen wird und man beginnt von neuem. Und wenn man einen Fork hat, dann wird es auch nicht einfacher, die Bugfixes aus den neuen Versionen in die alten einzubauen.
> Dafür gibt's aber auch Compiler.
Ich glaube, dass du wohl Crosscompiler meinst. Die werden mit Absicht nicht genommen, da eine native Übersetzung das System unter Last setzt und man schneller Systemfehler entdecken kann.
Mann ich sag ja auch nicht dass mein Pinguin schöner ist und mehr kann als dein Teufelchen, auch wenn es manchmal stimmt.
und nun kann man damit spielen und diesen bei Bedarf weiterentwickeln, der Rest ist Fantasie einiger GPL-Trolle.
Gruss,
demon
ccache is a compiler cache. It acts as a caching pre-processor to C/C++ compilers, using the -E compiler switch and a hash to detect when a compilation can be satisfied from cache. This often results in a 5 to 10 times speedup in common compilations.
Nur mal so...
Dieses "often" zweifel ich auch für nicht so "komischen Code" wie meinen Eiffel=>C Output an.
http://www.tendra.org/about/