pcc gibt (wieder) Lebenszeichen von sich

-Daemon-

Well-Known Member
Hallo allerseits,

gerade habe ich auf FreeBSD-current@ gelesen daß pcc wieder aus der "Versenkung aufgetaucht ist". Anders Magnusson hat sich seit einigen Jahren damit beschäftigt und hat sich jetzt aufgerappelt den Compiler so weit funktionsfähig zu machen um damit den Userspace von NetBSD/i386 kompilieren zu können.


Der Vollständigkeit halber hier seine komplette Mail:
(FYI: this mail was sent to a NetBSD mailing list, but it may be people interested of it here also)

Hm, I realized that there were more people interested in this compiler, so I'll send
a mail about it on these lists also. I have setup a mailing list about pcc, join it by:
_echo "subscribe pcc-list" | Mail majordomo@ludd.ltu.se_
or similar. There is also an embryo to a web page about pcc; http://www.ludd.ltu.se/~ragge/pcc/
which contains some basic information.

I have (as some people may know) been hacking on pcc for fun for some years.
After having that project on the shelf for a year or so, I decided to make the compiler
at least compile the NetBSD source tree again.

It is not yet bug-free, but it can compile the i386 userspace. The big benefit of it
(apart from that it's BSD licensed, for license geeks :-) is that it is fast, 5-10 times
faster than gcc, while still producing reasonable code. 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. Conversion to SSA format is also implemented,
but not yet the phi function. Not too difficult though, after that strength reduction is
high on the list.

It is also quite simple to port, writing the basics for i386 took three hours (hello world)
and complete port (pretty much as it is right now) two days.

I have added most of the C99 stuff (it is supposed to be a c99 compiler) but some stuff
is still missing, like the ability to do variable declarations anywhere (requires some
rewriting of the yacc code).

If someone wants to look at the compiler it can be fetched from ftp://226.net120.skekraft.net/pcc/pcc-current.tgz, current version is 0.9.8.

Currently only the i386 port is "supported", but there are a bunch of architectures
included that probably wont compile.

-- Ragge


Die OpenBSDler brauchen sich dann wohl doch nicht den Kopf über einen OpenCC zerbrechen :D
 
Nur als Anmerkung: OpenBSD hat den PCC ebenfalls ins CVS importiert.

Ich weiß leider noch nicht, was ich davon halten soll. Auf der einen Seite ist es schön, dass Anstrengungen unternommen werden eine Alternative zum recht fetten und vor GPLv3 lizensierten GCC zu finden. Zum Beispiel an PCC zu sehen oder auch an neuen Mitarbeitern beim Endlosprojekt TenDRA. Andererseits bindet dies nur Entwicklerkapazitäten, die dann wo anders fehlen... Dies ist vor allem der Fall, da in Sachen unterstützten Architekturen und Sprachen (Stichwort C++, wenigstens unter FreeBSD nötig) kein alternatives Projekt an den GCC heranreicht.
 
Ich weiß leider noch nicht, was ich davon halten soll.

Kein Problem, ich werd Dir mal kurz erzählen, was Du davon halten sollst ;)

Der "neue" Compiler hat einen großen Vorteil gegenüber dem GCC: Er compiliert schneller. Unter anderem macht er das dadurch, dass er keinen Optimierer besitzt. Das bedeutet, dasss zwar die Übersetzungszeit verkürzt wird, sich aber die Laufzeit der resultierenden Programme mit hoher Wahrscheinlichkeit erhöht.

Die kürzeren Übersetzungszeiten bedeuten, dass die Entwicklung (von jeglichem Code, der mit dem "schellen" Compiler übersetzt werden kann) beschleunigt wird: Wenn man nicht 2 Minuten auf das Compilat warten muss, sondern das Ergebnis schon nach 30 Sekunden erhält, ist es wesentlich einfacher und schneller möglich, einen Gedankengang zu verfolgen und auch zu verifizieren.

Ein weiterer Vorteil von nicht-optimiertem Code ist, dass der Compiler leichter zu verifizieren ist. Das gilt sowohl für den Compiler selbst als auch für den resultierenden Code. Wer halbwegs "flüssig" Assembler lesen und/oder schreiben kann, schafft es ohne große Mühen, nicht-optimierten Code zu disassemblieren und auch zu verstehen. Ein mit GCC und -O2 übersetztes Programm ist schon nicht mehr so einfach zu verstehen.

Ich denke daher dass der Import von PCC kein "Warnschuss" in Richtung GCC ist und den GCC nicht einmal mittelfristig ablösen wird. Auch sehe ich nicht, warum man den Compiler einzig wegen der Lizenz importieren hätte wollen (zugegeben, die Lizenz des PCC erleichtert den Import in die BSD Quellbäume). Meiner Meinung nach wurde der PCC einzig als Entwicklertool importiert.
 
Kein Problem, ich werd Dir mal kurz erzählen, was Du davon halten sollst ;)

Der "neue" Compiler hat einen großen Vorteil gegenüber dem GCC: Er compiliert schneller. Unter anderem macht er das dadurch, dass er keinen Optimierer besitzt. Das bedeutet, dasss zwar die Übersetzungszeit verkürzt wird, sich aber die Laufzeit der resultierenden Programme mit hoher Wahrscheinlichkeit erhöht.

Die kürzeren Übersetzungszeiten bedeuten, dass die Entwicklung (von jeglichem Code, der mit dem "schellen" Compiler übersetzt werden kann) beschleunigt wird: Wenn man nicht 2 Minuten auf das Compilat warten muss, sondern das Ergebnis schon nach 30 Sekunden erhält, ist es wesentlich einfacher und schneller möglich, einen Gedankengang zu verfolgen und auch zu verifizieren.
Wenn du einen schnellen Übersetzer willst, dann teste mal den TCC - da schlackern dir die Ohren.

Ein weiterer Vorteil von nicht-optimiertem Code ist, dass der Compiler leichter zu verifizieren ist. Das gilt sowohl für den Compiler selbst als auch für den resultierenden Code. Wer halbwegs "flüssig" Assembler lesen und/oder schreiben kann, schafft es ohne große Mühen, nicht-optimierten Code zu disassemblieren und auch zu verstehen. Ein mit GCC und -O2 übersetztes Programm ist schon nicht mehr so einfach zu verstehen.
Vergiss die Idee einfach. Programmverifikation ist schon seit Jahrzehnten ein leidiges Thema. Bei etwas komplexem - und komplex heißt soviel wie "enthält etwas, was nicht nur eine einfache Zählschleife ist" - ist mit Verifikation einfach Banane (ok, etwas überspitzt, andererseits passt Übersetzer auch nicht auf zwei Bildschirmseiten).


Ich finde diesen Satz lustig:
Conversion to SSA format is also implemented, but not yet the phi function.
Wer sich ein klein wenig mit Übersetzerbau auskennt, muss hier einfach nur den Kopf schütteln. Phi-Funktionen sind /der/ zentrale Aspekt an SSA. Das hat etwa die Qualität von "Ich habe ein Haus gebaut - nur die Wände fehlen noch".
 
. Andererseits bindet dies nur Entwicklerkapazitäten, die dann wo anders fehlen...
Hallo,
dieses Argument finde ich immer ein wenig seltsam, hätten die Entwickler interesse z.B. am gcc mitzuwirken, dann würden sie das doch tun. Sonst würden sie sich ja nicht einem Alternativ-Projekt zuwenden. Wenn es dieses nicht gäbe, dann würden sie es entweder selbst gründen oder einfach komplett wegbleiben.

marmorkuchen
 
Es mag daran liegen, dass man mir seit Jahr und Tag im Studium einredet gefälligst in globalen Strukturen zu denken und Arbeitskräfte als austauschbares Material zu sehen ;)
 
Es mag daran liegen, dass man mir seit Jahr und Tag im Studium einredet gefälligst in globalen Strukturen zu denken und Arbeitskräfte als austauschbares Material zu sehen ;)

Hat man dir auch erzählt, dass man ein Baby in 4,5 Monaten bekommen kann, indem man einfach zwei Frauen schwängert? *g*
 
Nur 4,5 Monate? Das enttäuscht mich. Durch Arbeitsteilung und Austausch von Erkenntnissen müsste sich das ohne Probleme auf 3 Monate drücken lassen...
 
Nur 4,5 Monate? Das enttäuscht mich. Durch Arbeitsteilung und Austausch von Erkenntnissen müsste sich das ohne Probleme auf 3 Monate drücken lassen...

Multithreading war schon immer etwas schwierig ;)

oder anders ausgedrückt (die gute alte 3-Satz-Rechnung):
wenn 3 Frauen, 3 Kinder in 9 Monaten kriegen,
und 1 Kind 9 Monate dauert,
wielange braucht dann eine Frau um 3 Kinder zu bekommen ;)

döna
 
Zurück
Oben